* How does gdb deal with bizarre frame descriptions?
@ 2010-05-18 20:06 Tom Horsley
2010-05-19 22:42 ` Mike Frysinger
0 siblings, 1 reply; 3+ messages in thread
From: Tom Horsley @ 2010-05-18 20:06 UTC (permalink / raw)
To: gdb
I've been looking at the frame info for a main program
compiled on ubuntu with g++ (4.4.3), and the frame description
info, both for the eh_frame CFA and the DW_AT_frame_base
attribute is totally bizarre. The frame pointer is described
as being at *(ebp - 16) (for a certain range of addresses).
If I debug this program with gdb, it seems to get the frame
info correct, and apparently believes the frame pointer
is the ebp register (which seems to make sense if I
disassemble the code). If I look in *(ebp - 16) I see
trash.
What the devil is gdb doing to get this right? Is it
utterly ignoring the trash generated by the compiler and
deducing the frame description by disassembling the
prologue code or something?
gdb version: GNU gdb (GDB) 7.1-ubuntu
g++ version: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
architecture: i686
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How does gdb deal with bizarre frame descriptions?
2010-05-18 20:06 How does gdb deal with bizarre frame descriptions? Tom Horsley
@ 2010-05-19 22:42 ` Mike Frysinger
2010-05-20 0:21 ` Tom Horsley
0 siblings, 1 reply; 3+ messages in thread
From: Mike Frysinger @ 2010-05-19 22:42 UTC (permalink / raw)
To: gdb; +Cc: Tom Horsley
[-- Attachment #1: Type: Text/Plain, Size: 1205 bytes --]
On Tuesday 18 May 2010 16:05:54 Tom Horsley wrote:
> I've been looking at the frame info for a main program
> compiled on ubuntu with g++ (4.4.3), and the frame description
> info, both for the eh_frame CFA and the DW_AT_frame_base
> attribute is totally bizarre. The frame pointer is described
> as being at *(ebp - 16) (for a certain range of addresses).
>
> If I debug this program with gdb, it seems to get the frame
> info correct, and apparently believes the frame pointer
> is the ebp register (which seems to make sense if I
> disassemble the code). If I look in *(ebp - 16) I see
> trash.
>
> What the devil is gdb doing to get this right? Is it
> utterly ignoring the trash generated by the compiler and
> deducing the frame description by disassembling the
> prologue code or something?
>
> gdb version: GNU gdb (GDB) 7.1-ubuntu
> g++ version: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
> architecture: i686
look at the frames sections of the gdb internals manual as it describes the
algorithms gdb uses (or rather, the framework gdb has that each arch/port
extends).
you can also use 'set debug frame 1' to get more insight on the frame
construction.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How does gdb deal with bizarre frame descriptions?
2010-05-19 22:42 ` Mike Frysinger
@ 2010-05-20 0:21 ` Tom Horsley
0 siblings, 0 replies; 3+ messages in thread
From: Tom Horsley @ 2010-05-20 0:21 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb
On Wed, 19 May 2010 18:41:59 -0400
Mike Frysinger wrote:
> look at the frames sections of the gdb internals manual as it describes the
> algorithms gdb uses (or rather, the framework gdb has that each arch/port
> extends).
>
> you can also use 'set debug frame 1' to get more insight on the frame
> construction.
Thanks for the pointers, but I think I have discovered that the
compiler is actually generating correct, but ridiculous frame info.
The code really is using ebp as a frame register, but it also
has stored a copy of the frame pointer on the stack and described
that saved copy in the dwarf instead of just using ebp+offset
like all the code it generated actually does. I have no clue
why it does that :-).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-05-20 0:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-18 20:06 How does gdb deal with bizarre frame descriptions? Tom Horsley
2010-05-19 22:42 ` Mike Frysinger
2010-05-20 0:21 ` Tom Horsley
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).