Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
To: cagney@gnu.org (Andrew Cagney)
Cc: cagney@gnu.org (Andrew Cagney),
	kettenis@chello.nl (Mark Kettenis),
	weigand@i1.informatik.uni-erlangen.de (Ulrich Weigand),
	gdb-patches@sources.redhat.com, uweigand@de.ibm.com
Subject: Re: [PATCH] S/390 DWARF-2 CFI frame support
Date: Wed, 10 Dec 2003 18:52:00 -0000	[thread overview]
Message-ID: <200312101852.TAA16413@faui1d.informatik.uni-erlangen.de> (raw)
In-Reply-To: <3FD7548D.7080300@gnu.org> from "Andrew Cagney" at Dec 10, 2003 12:14:53 PM

Andrew,

> > I'm wondering if it would be easier, here to "give up".  Throw the whole problem back at the architecture vis:
> > 
> > - initialize unwind table using per OSABI (?) method
> > 
> > - update the unwind table using the CFI initialize info
> > 
> > - update the unwind table using the PC's CFI unwind info
> > 
> > - if after all this a register is still unspecified, we complain
> > (btw, the compaint is only ment to appear once but apparently appears repeatedly?).
> > 
> > Thoughts for the moment on the theory?  Mark?

I don't quite see how to map the existing issues in this ABI:

- On s390, we need to copy %r14 *after it was unwound* to the PC
  register.  I see how to do that if an arch-specific routine is
  called after the CFI data is parsed, but not how to do it if
  the arch-specific routine is called *before*.

- On x86_64, you need to specific that the stack pointer is unwound
  to the CFA.  How should the arch-specific routine do that?
  (Again, if the arch-specific routine were called after the CFI
  is parsed, it could presumably copy the expression for the CFA
  as stack pointer unwind expression.  But before?)

However, this interface would solve the call-saved registers issue.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de


  reply	other threads:[~2003-12-10 18:52 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 [this message]
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

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