From: Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz>
To: Daniel Berlin <dberlin@dberlin.org>,
Richard Henderson <rth@redhat.com>,
gdb@sources.redhat.com
Subject: Re: Problem with location lists and variables on stack
Date: Wed, 08 Oct 2003 05:09:00 -0000 [thread overview]
Message-ID: <20031008050857.GA14575@artax.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20031007214832.GA11708@nevyn.them.org>
> > >>Daniel Berlin has already written support for GCC to generate location
> > >>list for DW_AT_frame_base.
> > >>DW_AT_frame_base is a location list as any other (actually only the
> > >>offsets relatively to original stack pointer at function start are
> > >>needed).
> > >>GDB then uses this location list to adjust offsets of other variables
> > >>addressed using stack pointer.
> > >>With Daniel Jacobowitz's fix for GDB it works :-)
> > >>i.e. you can see correct values for variables located on stack
> > >>even when stack pointer changes because of push, pop, etc.
> > >>
> > >>Current GCC patch can be downloaded from:
> > >>http://artax.karlin.mff.cuni.cz/~zlomj9am/download/vt-main.patch
> > >>
> > >>(because currently GCC is in stage 2 it has to wait until GCC is in
> > >>stage 1)
> > >
> > >I suppose this is true, but it's really unfortunate.
> >
> > I'm not so sure it's true.
> >
> > This isn't a major change, really and it's only going to make things
> > better (We didn't use to support -O2 -g at all, really, and now we can.
> > There can't be any regressions from an unsupported state to a
> > supported one). It's also not an optimization pass, so the risk is
> > relatively low.
>
> Well, FWIW I'd like to see this included. Josef, do you have any
> interest in submiting it for 3.4, to see what reaction it gets at least?
I'll try to submit it for 3.4. If it is disabled for default and
enabled only explicitelly with -fvar-tracking the risk of breaking
something will be very low.
Anyway, I'm planning to commit it to hammer-3_3-branch (enabled by default)
as soon as I backport some patches needed by variable tracking from
mainline.
Josef
prev parent reply other threads:[~2003-10-08 5:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-01 14:43 Josef Zlomek
2003-10-01 14:49 ` Daniel Jacobowitz
2003-10-01 15:21 ` Josef Zlomek
2003-10-01 15:44 ` Josef Zlomek
2003-10-01 15:54 ` Daniel Jacobowitz
2003-10-01 16:03 ` Josef Zlomek
2003-10-01 16:22 ` Daniel Jacobowitz
2003-10-01 17:41 ` Josef Zlomek
2003-10-01 17:44 ` Daniel Jacobowitz
2003-10-01 17:48 ` Josef Zlomek
2003-10-06 6:22 ` Richard Henderson
2003-10-06 6:40 ` Josef Zlomek
2003-10-06 13:46 ` Daniel Jacobowitz
2003-10-06 14:49 ` Daniel Berlin
2003-10-07 21:48 ` Daniel Jacobowitz
2003-10-08 5:09 ` Josef Zlomek [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=20031008050857.GA14575@artax.karlin.mff.cuni.cz \
--to=zlomj9am@artax.karlin.mff.cuni.cz \
--cc=dberlin@dberlin.org \
--cc=gdb@sources.redhat.com \
--cc=rth@redhat.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