Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: cagney@gnu.org
Cc: cagney@gnu.org, 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: Fri, 12 Dec 2003 17:43:00 -0000	[thread overview]
Message-ID: <200312121741.hBCHfeRW036656@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3FD7548D.7080300@gnu.org> (message from Andrew Cagney on Wed, 10 Dec 2003 12:14:53 -0500)

I've been thinking about this over the last few days, but I haven't
reached a conclusion yet.

I've considered per-architecture initialization of the unwind table
before.  However, the things Richard Henderson says about treating
uninitialized columns as "same value" make sense.  And as Ulrich
pointed out, it doesn't immediately solve our problems with the PC and
SP.

On the other hand, we should be able to introduce our own "rules" in
addition to the ones given by the DWARF2/3 specification.  We could
add the following two:

* REG_RETURN_ADDRESS: Set the particular register to the return
  address of the function.

* REG_CFA: Set the particular register to the call frame address.

We could even allow for an offset, such that we could specify rules
such as: set the ISA PC register to the return address plus an offset
of 8 bytes, or set the ISA SP register to the call frame address plus
minus an offset of 128 bytes.  I might need such a facility for SPARC.

How does that sound?

In the meantime, I'm going to try to remove some of the PC and
SP-related hacks in dwarf2-frame.c and see what happens.

Mark


  parent reply	other threads:[~2003-12-12 17:43 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 [this message]
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=200312121741.hBCHfeRW036656@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