Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: cagney@gnu.org
Cc: weigand@i1.informatik.uni-erlangen.de,
	gdb-patches@sources.redhat.com, uweigand@de.ibm.com
Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support
Date: Sun, 14 Dec 2003 17:16:00 -0000	[thread overview]
Message-ID: <200312141714.hBEHEqU2014090@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3FDC9292.6030601@gnu.org> (message from Andrew Cagney on Sun, 14 Dec 2003 11:40:50 -0500)

   Date: Sun, 14 Dec 2003 11:40:50 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > The reason why I added that hack in the first place is the case where
   > the return address column does not correspond to an actual register.
   > In that case we must make sure that we don't map it onto one of GDB's
   > (pseudo-)registers.  Assuming that the compiler has some freedom in
   > choosing the return address column number, and considering that the
   > DWARF-2 register numbers are largely undocumented for most targets, I
   > was worried that I couldn't guarantee this.
   > 
   > AFAICT there is no platform yet where GCC uses a return address column
   > number that would be mapped on the wrong GDB register, so I think we
   > can safely remove the code.  New targets that start using the DWARF-2
   > CFI stuff should make sure theur DWARF-2 register number mapping is
   > right.

   Well, ... the PPC64 return-column, when I last looked, specified the 
   dwarf2' floating-point status and control register number!  But let the 
   person framifying the PPC64 sort that one out :-)

Argh!  Someone teach GCC about the PPC64 DWARF register numbering
please!  Before it is too late!  Now it is using the PPC32 LR register
number, which just happens to be the PPC64 FPSCR register.

   Anyway, with respect to your proposal, yes like it.

I'll see whether I can implement it.

Mark



      reply	other threads:[~2003-12-14 17:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04 20:09 Ulrich Weigand
2003-12-04 22:47 ` Jim Blandy
2003-12-05  0:49 ` Richard Henderson
2003-12-05  1:04   ` Andrew Cagney
2003-12-05  1:44     ` Richard Henderson
2003-12-05  2:03   ` Ulrich Weigand
2003-12-05  2:11     ` Richard Henderson
2003-12-05  2:16       ` Ulrich Weigand
2003-12-05  2:13     ` Daniel Jacobowitz
2003-12-05  2:19       ` Ulrich Weigand
2003-12-05 16:02 ` Andrew Cagney
2003-12-05 17:54   ` Ulrich Weigand
2003-12-10 17:14   ` Andrew Cagney
2003-12-10 18:52     ` Ulrich Weigand
2003-12-12 17:43     ` Mark Kettenis
2003-12-13 15:32       ` Ulrich Weigand
2003-12-14 15:23         ` Mark Kettenis
2003-12-14 16:40           ` Andrew Cagney
2003-12-14 17:16             ` Mark Kettenis [this message]

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=200312141714.hBEHEqU2014090@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=uweigand@de.ibm.com \
    --cc=weigand@i1.informatik.uni-erlangen.de \
    /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