From: Jim Blandy <jimb@red-bean.com>
To: gdb@sources.redhat.com
Subject: Fwd: frame_id question
Date: Fri, 11 Nov 2005 18:05:00 -0000 [thread overview]
Message-ID: <8f2776cb0511111005p7def7f5dv518fd2f9674e4b76@mail.gmail.com> (raw)
In-Reply-To: <8f2776cb0511110943p1bb2b03g1b158fb8a82f2528@mail.gmail.com>
---------- Forwarded message ----------
From: Jim Blandy <jimb@red-bean.com>
Date: Nov 11, 2005 9:43 AM
Subject: Re: frame_id question
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Jim Blandy <jimb@redhat.com>, gdb@sources.redhat.com
On 11/11/05, Vladimir Prus <ghost@cs.msu.su> wrote:
> Do I understand correctly that this can happen only on architectures where
> return address is not automatically pushed to the stack, but moved to a
> special register? Like MIPS's "jal" instructions that moves return address to
> $31
Yes, that's right.
> Does it mean that for architectures with automatic pushing of return address,
> using '0' as code address in frame_id will be safe? Or there are some corner
> cases?
I think this is true. It used to be that some architectures used the
top of the stack as the frame ID's stack address (even though this is
wrong: a call to alloca could change the sp, or the code itself could
push and pop things for its own reasons; either would produce a "new"
frame ID when no call, return, or longjmp has taken place). On these
architectures, I think you could run into problems.
But the modern thing to do is to use the base of the stack frame ---
the top of the stack upon entry to the function, or some fixed offset
from that --- as the frame ID's stack address. When you have Dwarf
CFI for the function, we use the Dwarf CFA for the frame ID stack
address, which meets those qualifications. I'm not sure what the code
address would be needed for in those architectures.
If you're porting to a new architecture, you'll want to go through
the test suite results very carefully to look for stack unwinding
problems.
next prev parent reply other threads:[~2005-11-11 18:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-09 16:29 Vladimir Prus
2005-11-11 10:23 ` Jim Blandy
2005-11-11 10:35 ` Vladimir Prus
[not found] ` <8f2776cb0511110943p1bb2b03g1b158fb8a82f2528@mail.gmail.com>
2005-11-11 18:05 ` Jim Blandy [this message]
2005-11-13 17:32 ` Daniel Jacobowitz
2005-11-13 23:34 ` Jim Blandy
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=8f2776cb0511111005p7def7f5dv518fd2f9674e4b76@mail.gmail.com \
--to=jimb@red-bean.com \
--cc=gdb@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).