From: Daniel Jacobowitz <drow@false.org>
To: Randolph Chung <randolph@tausq.org>
Cc: Jim Blandy <jimb@red-bean.com>, gdb@sources.redhat.com
Subject: Re: Argument pointers, dwarf and prologue analysis
Date: Mon, 21 Nov 2005 14:08:00 -0000 [thread overview]
Message-ID: <20051121140809.GA18686@nevyn.them.org> (raw)
In-Reply-To: <4381A22B.20707@tausq.org>
On Mon, Nov 21, 2005 at 06:32:11PM +0800, Randolph Chung wrote:
> >I don't think that the wacky idea about recovering r20's value by
> >looking at the call site will work. I mean, if r20 is a scratch
> >register, you have no way of knowing that it hasn't been used for
> >something else since the function was entered, right? I admit I don't
> >really understand that.
>
> Well, for gcc, preceeding every call will be a setting of the argument
> pointer is a relative offset to the stack pointer. We only need to know
> the value of r29 and r20 during the prologue, so I would argue that if
> we know the value of r29 immediately before the call (at the call site),
> then prologue analysis will be able to tell you where the arguments are
> stored.
>
> that is, there will always be:
>
> caller:
> ...
> ldo -48(%sp), %r29
> ...
> bl callee, %r2
>
> callee:
> ...
> ldo -64(%r29), %r20
> stw %arg0, 4(%r20)
> ...
> <after prologue insns>
So you're saying you have to do (A) backwards code analysis from the
call site to compute r29, and then (B) forward code analysis from the
function start to compute r20 relative to r29, and then (C) use dwarf
debug information to find arguments relative to r20, and then (D) hope
that GCC doesn't decide to use r20 for something different, since it
doesn't seem to be a traditional "frame pointer"? There's a lot more
prayer in that method than there really ought to be. And GCC will
probably take some severe liberties with where the set of %r29 is, so
I'm skeptical that you can do the call site analysis.
How does GDB cope today? A lot of guessing and failing?
I'd recommend ignoring the call site/ABI bits. They're too unreliable.
The real problem is that you can't recover %r20. You're thinking in
terms of finding the offset relative to the CFA where these things are
stored, which is why you've got a solution that relies on analyzing the
caller. But think about the problem in terms of the callee for a
moment. The function doesn't care what the offset relative to the CFA
is. It cares what the offset relative to the incoming %r29 and later
%r20 is. And then, if it makes any calls, it had better still know
where its own arguments went! So that should be in the debug info
somehow.
We've got dwarf unwind information to play with now. Even with the new
additions in dwarf3, it's not so good at representing what you need.
I'd need to see a larger example to know how we could, or couldn't, do
this.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-11-21 14:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 5:50 Randolph Chung
2005-11-21 7:42 ` Jim Blandy
2005-11-21 10:32 ` Randolph Chung
2005-11-21 14:08 ` Daniel Jacobowitz [this message]
2005-11-21 15:11 ` Randolph Chung
2005-11-21 15:26 ` Daniel Jacobowitz
2005-11-22 0:07 ` Randolph Chung
2005-11-22 5:15 ` Jim Blandy
2005-11-22 6:39 ` Randolph Chung
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=20051121140809.GA18686@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=jimb@red-bean.com \
--cc=randolph@tausq.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