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
next prev parent 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