From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames
Date: Wed, 23 Apr 2008 13:44:00 -0000 [thread overview]
Message-ID: <20080423125410.GA19773@caradoc.them.org> (raw)
In-Reply-To: <18447.12269.389044.431822@kahikatea.snap.net.nz>
On Thu, Apr 24, 2008 at 12:47:41AM +1200, Nick Roberts wrote:
> > My biggest worry about this is that we'll be providing some information
> > which is highly compiler dependent and which we cannot document in any way
> > other that "it is hex number". I don't think a random frontend author knows
> > what DWARF CFI is :-)
>
> If it was just a hex number, the concept of frame address presumably wouldn't
> exist. To me, it refers to the start of the frame and if a variable has an
> address below that value, it belongs to that frame or a higher one. Maybe on
> some architectures, the stack grows in the other direction, and maybe there are
> other anomalies, but a user could understand this and interpret such numbers.
My concern about this has been, and still is, that front ends will
assign more meaning to it than it really has. This is one of the
trickiest parts of GDB. We already use frame addresses (specifically
$fp) to create varobjs in non-current frames; this is basically the
only thing the entire complicated frame_base machinery is used for
when not using stabs and it really should go away.
How about we call it the stack address of the frame instead of the
frame address? Then it can come from the unwound $sp, which will
be at the other end of the frame and is better defined.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-04-23 12:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 5:33 Nick Roberts
2008-04-23 5:48 ` Vladimir Prus
2008-04-23 6:03 ` Nick Roberts
2008-04-23 6:16 ` Vladimir Prus
2008-04-23 9:50 ` Nick Roberts
2008-04-23 10:32 ` Vladimir Prus
2008-04-23 13:23 ` Nick Roberts
2008-04-23 13:44 ` Daniel Jacobowitz [this message]
2008-04-23 23:04 ` Nick Roberts
2008-04-23 23:27 ` Daniel Jacobowitz
2008-04-24 0:40 ` Bob Rossi
2008-04-24 1:45 ` Nick Roberts
2008-04-24 1:31 ` Nick Roberts
2008-04-24 1:48 ` Nick Roberts
2008-04-24 10:24 ` Daniel Jacobowitz
2008-04-25 1:48 ` Nick Roberts
2008-04-25 2:03 ` Daniel Jacobowitz
2008-04-25 11:41 ` Nick Roberts
2008-04-23 13:53 ` Vladimir Prus
2008-04-23 23:23 ` Nick Roberts
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=20080423125410.GA19773@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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