Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Michal Ludvig <mludvig@suse.cz>, Gerhard Tonn <TON@de.ibm.com>
Cc: gdb-patches@sources.redhat.com, Jim blandy <jimb@redhat.com>,
	Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [PATCH RFC] DWARF2 CFI exploitation for Linux on S/390
Date: Thu, 26 Sep 2002 19:54:00 -0000	[thread overview]
Message-ID: <3D93C87C.4050603@redhat.com> (raw)
In-Reply-To: <3D91908A.8030308@suse.cz>


> In order to adapt the code to the first item, I have introduced #defines
> for DWARF2 registers and a REGNUM_TO_DWARF2_REG macro and its
> implementation. See the attached patch for details.

Looking just at the gdbarch.h addition REGNUM_TO_DWARF2_REG().  Is it 
possible to compute this using DWARF2_REGNUM_TO_REGNUM() or [better?] 
have dwarf2cfi convert everything to GDB regnums.  Having everything in 
GDB REGNUM's would take away any need for conversion confusion.

Also note:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=325

The current code contains things like:
   int regs_size = sizeof (struct context_reg) * NUM_REGS;
but it should be using (NUM_REGS + NUM_PSEUDO_REGS) because there is a 
very good chance that the REGNUM returned by DWARF2_REG_TO_REGNUM() is 
in the range [NUM_REGS .. NUM_REGS+NUM_PSEUD_REGS).

> In order to consider the second item I have adapted the LOC_REF_ARG symbol
> class handling in dwarf2read.c and findvar.c to use the BASEREG value if
> DWARF2 is active.

>> 
>> Finally I am interested in how signal frame and dummy frame handling is
>> supposed to work with DWARF2 CFI support. Does anybody have done already
>> work in this area?
>> 

> That's the question I'm solving too. The first approach (for x86-64) is here: http://sources.redhat.com/ml/gdb-patches/2002-09/msg00384.html
> Basically I don't set_gdbarch_*() directly to cfi_*() functions but instead to corresponding x86_64_*() functions, that eventually call cfi_*() themselves. For sighandler caller frames I'm afraid I'll have to manually fill appropriate structures in struct context (probably in those x86_64_*() functions).

See: http://sources.redhat.com/ml/gdb/2002-09/msg00301.html

The theory is that each frame has frame specific methods: 
register-unwind, saved-pc (and frame-chain(?)).

So far a recursive frame->unwind() method has been added and all 
evidence suggests it is working well.  The CFI code needs to be updated 
to work with that interface, and also work with the current 
regcache.[hc] interface.

enjoy,
Andrew



  reply	other threads:[~2002-09-27  2:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-24  5:23 Gerhard Tonn
2002-09-25  3:31 ` Michal Ludvig
2002-09-26 19:54   ` Andrew Cagney [this message]
2002-09-30  7:51     ` Michal Ludvig
2002-09-30  8:24       ` Hans-Peter Nilsson
2002-09-30  8:53       ` Andrew Cagney

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=3D93C87C.4050603@redhat.com \
    --to=ac131313@redhat.com \
    --cc=TON@de.ibm.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=mludvig@suse.cz \
    /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