This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Add sparc64-linux sigtramp support
On Sat, 23 Apr 2005 14:32:56 +0200 (CEST)
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> Hmm, the SCD 2.4.1 document that I'm looking at now says there are 32K
> entries of 32 bytes followed by sections of 160 24-byte entries
> followed by 160 pointers.
The first part is correct, there are 32K pure code entries.
The latter section is "160 24-byte entries followed by
160 pointers" for every full group of 160 entries, for the
final group that has less than 160 entries (say N entries) it is
N 24-byte entries followed by N pointers.
The formulas to compute this stuff are pretty well described
in the sparc64 BFD backend support code. Search for
"h->plt.offset" and "build_plt_entry" in the current bfd/elfxx-sparc.c
code.
> I'm not sure it really matters though.
> IIRC the most important thing is to avoid thinking that the PLT is a
> proper function that starts with setting up a stack frame. Did you
> notice any problems with the current code.
Yes, there is a test case that fails on sparc32 for at least the
past 8 years that's been bugging me like crazy.
Basically it's trying to step over an integer multiply in a piece
of C code, via a watchpoint. It's 32-bit Sparc compiled code with
no hw multiply support, so to implement the multiply it calls ".umul"
in the C library via a PLT entry.
GDB outside of my own trees has never handled this test correctly
and it's because of the PLT frame handling.
The PLT trampoline _does_ have a frame, the issue is only to teach
the Sparc target dependant code where to find the restore which
releases the frame.
Anyways, let me dig through my old patches and notes I took on this
matter. I'll use that to come up with a solution proposal.
> Looks to me as if the sparc PLT entries are deliberately constructed a
> way to avoid the PLT breakpoint issue the ppc-linux-tdep.c code tries
> to solve. That said, moving that code into a common file is probably
> a good idea.
It has the same problem. If you set a breakpoint in the second instruction
of a PLT entry while we're in the dynamic linker resolve code, the dynamic
linker will write the new instructions in the PLT entry, then GDB will
restore the old out-of-date instruction when it removes the breakpoint it
had there, thus corrupting the PLT entry and causing a crash the next time
the child calls that function via that PLT entry.
Like the above, I'll come up some specific test cases and fix proposals
over the next few days for this stuff.