This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add sparc64-linux sigtramp support


   Date: Fri, 22 Apr 2005 15:38:35 -0700
   From: "David S. Miller" <davem@davemloft.net>

   Mark do you actually have a sparc-linux machine that you test
   your changes on?  Your solaris2 tdep removal breaks even
   the most simplest debugging test case, there is no way you
   tested sparc64-linux debugging.

I'm working on it now ;-).

   You're not calling sparc64_init_abi() anymore.  Once you
   remove the call to sparc64_sol2_init_abi() it's not occuring
   at all.

Sorry 'bout that.  Thanks for fixing this.

   If you don't have a sparc*-linux machine to test your changes
   on, please at least run them by me quickly so I can run the
   testsuite on both 32-bit and 64-bit native Linux/Sparc.

   BTW, the plt entry size stuff is wrong.  It was wrong for
   the solaris2 sparc64 target and it's wrong for the Linux
   target as well.  They are variable in size, the first 64K
   of them are 16 bytes in size, then they become variable
   length sections of split instructions+data.

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.  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.

That said, it looks like we should at least change the 16 into 32 and
add a comment about the >32K PLT entries.

   I think we should instead either teach gdb how to really get
   the correct frame even in the funny PLT entry save/restore
   sequence (I had this working flawlessly a few years ago, I
   could resurrect that code) or we could do something similar to
   what the ppc-linux-tdep.c code does.  I also think we should
   integrate the "PLT breakpoint avoidance" stuff they do there
   as well (and move that into a common file as the comment
   above it suggests).

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.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]