Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: davem@davemloft.net
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Add sparc64-linux sigtramp support
Date: Sat, 23 Apr 2005 12:33:00 -0000	[thread overview]
Message-ID: <200504231232.j3NCWuZT029533@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050422153835.12aaf3c1.davem@davemloft.net>

   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


  reply	other threads:[~2005-04-23 12:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21  3:51 David S. Miller
2005-04-21 19:23 ` Mark Kettenis
2005-04-21 19:29   ` David S. Miller
2005-04-21 21:20     ` Mark Kettenis
2005-04-21 21:41       ` David S. Miller
2005-04-21 21:57         ` Mark Kettenis
2005-04-21 22:04           ` David S. Miller
2005-04-21 21:55       ` David S. Miller
2005-04-21 22:09         ` Mark Kettenis
2005-04-22 22:45           ` David S. Miller
2005-04-23 12:33             ` Mark Kettenis [this message]
2005-04-23 17:47               ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504231232.j3NCWuZT029533@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=davem@davemloft.net \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox