* Argument pointers, dwarf and prologue analysis
@ 2005-11-21 5:50 Randolph Chung
2005-11-21 7:42 ` Jim Blandy
0 siblings, 1 reply; 9+ messages in thread
From: Randolph Chung @ 2005-11-21 5:50 UTC (permalink / raw)
To: gdb
Here's another interesting bit from HPPA's abi -- on 64-bit, the HPPA
ABI uses an "argument pointer" (r29) that points inside the stack frame
for storing various things. The argument pointer is set by the caller,
and is *not* a call preserved register. Moreover, in gcc, in the callee
frame, the compiler will compute an offset to r29, and use that to store
the arguments. For example:
foo
.PROC
.CALLINFO FRAME=80,NO_CALLS,SAVE_SP,ENTRY_GR=3
.ENTRY
copy %r3,%r1
copy %r30,%r3
std,ma %r1,80(%r30)
std %r3,-8(%r30)
ldo -64(%r29),%r20
stw %r26,4(%r20)
stw %r25,12(%r20)
stw %r24,20(%r20)
[...]
Here, r20 is a scratch register (also not call preserved). r26, r25, r24
are the first three arguments to the function.
Based on the above code, the dwarf debug info emitted describes the
arguments using DW_OP_breg20 {4,12,20}
This causes obvious problems when trying to retrieve arguments from
outer frames, for example:
int foo(int a, int b, int c, int d, int e, int f, int g, int h)
{
return a+b+c+d+e+f+g+h;
}
int bar(int a, int b, int c, int d, int e, int f, int g, int h)
{
return foo(a+1, b+1, c+1, d+1, e+1, f+1, g+1, h+1);
}
int main(int argc, char **argv)
{
return bar(1,2,3,4,5,6,7,8);
}
in foo, the arguments to bar are incorrectly read because r20 may have
been clobbered and cannot be recovered (currently).
Possibly, gcc should be changed to generate code that stores arguments
based on a call preserved register, but in talking with Dave Anglin, it
seems this is not so straightforward. He also suggested another idea:
In fact, r20 above can be determined by looking at the caller frame (bar
in the example). A few insn before the call to foo, you will find:
ldo -48(%r30),%r29
copy %r27,%r4
b,l foo,%r2
r30 is the stack pointer. So, theoretically, one could find the return
pointer of the current frame, look at a few insns before that point,
determine the offset from the frame base of the current frame, then
adjust that based on the ldo insn in the prologue in the current frame
to get the value of r20, and store that value in the frame cache. Then,
the dwarf evaluation will be able to read the argument values from the
correct location. Whew!
Before I go and try to implement this mess, I would like to get some
feedback about whether this seems to be a good solution. Are there
better ways to do this? Can we simply make gcc emit a few more dwarf ops
to describe all the offsets and pointers that are involved?
Comments much appreciated :)
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 5:50 Argument pointers, dwarf and prologue analysis Randolph Chung
@ 2005-11-21 7:42 ` Jim Blandy
2005-11-21 10:32 ` Randolph Chung
0 siblings, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2005-11-21 7:42 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb
It seems to me that the real problem is that the Dwarf debugging info
doesn't accurately describe where the bar's arguments live after the
call to foo. That is, when you return from foo, since r20 is
caller-saved, its value is unknown, and it's incorrect for the
debugging info to claim that the debugger can find the variables
relative to its value.
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.
But I think it's clear that the locations of the variables in the
debug info is incorrect. There's all kinds of heuristic crud in
gcc/dwarf2out.c where it tries to figure out the right register to use
as the base for variable locations (maybe I'm thinking of the way the
CFI code chooses a CFA register; I don't really remember), but it
seemed like it could be easily confused by the use of temporaries like
r20 in the example you posted.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 7:42 ` Jim Blandy
@ 2005-11-21 10:32 ` Randolph Chung
2005-11-21 14:08 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Randolph Chung @ 2005-11-21 10:32 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
> It seems to me that the real problem is that the Dwarf debugging info
> doesn't accurately describe where the bar's arguments live after the
> call to foo. That is, when you return from foo, since r20 is
> caller-saved, its value is unknown, and it's incorrect for the
> debugging info to claim that the debugger can find the variables
> relative to its value.
Yeah, I filed a gcc bug about this yesterday....
> 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>
randolph
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 10:32 ` Randolph Chung
@ 2005-11-21 14:08 ` Daniel Jacobowitz
2005-11-21 15:11 ` Randolph Chung
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-11-21 14:08 UTC (permalink / raw)
To: Randolph Chung; +Cc: Jim Blandy, gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 14:08 ` Daniel Jacobowitz
@ 2005-11-21 15:11 ` Randolph Chung
2005-11-21 15:26 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Randolph Chung @ 2005-11-21 15:11 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Jim Blandy, gdb
> 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.
Yeah...., except it doesn't have to be r20, it can be any register.
> 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.
yes, that's what i worry about too....
> How does GDB cope today? A lot of guessing and failing?
It doesn't -- basically I discovered this because on hppa64-*, if you do
a backtrace, gdb prints completely bogus arguments for anything other
than the innermost frame.
> 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.
Oh, I agree -- my first instinct is that gcc is wrong in writing the
debug info based on r20.... in fact I filed this as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943 before I wrote my
email to this list; but some emails I had with Dave convinced me that
the problem is not as easy as I thought it would be, so I thought I'd
bring it up here...
> 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.
What would you like to see?
randolph
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 15:11 ` Randolph Chung
@ 2005-11-21 15:26 ` Daniel Jacobowitz
2005-11-22 0:07 ` Randolph Chung
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-11-21 15:26 UTC (permalink / raw)
To: Randolph Chung; +Cc: Jim Blandy, gdb
On Mon, Nov 21, 2005 at 11:10:46PM +0800, Randolph Chung wrote:
> >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.
>
> What would you like to see?
How about full assembly and debug info for some case we get wrong? At
least three frames where the middle one uses its arguments after the
call site, so we have a non-leaf function to look at.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-21 15:26 ` Daniel Jacobowitz
@ 2005-11-22 0:07 ` Randolph Chung
2005-11-22 5:15 ` Jim Blandy
0 siblings, 1 reply; 9+ messages in thread
From: Randolph Chung @ 2005-11-22 0:07 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Jim Blandy, gdb
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
> How about full assembly and debug info for some case we get wrong? At
> least three frames where the middle one uses its arguments after the
> call site, so we have a non-leaf function to look at.
ok, here we go:
tausq@hiauly3:~$ cat dwarfbug.c
void foo(int a, int b, int c, int d, int e)
{
a = a;
}
void bar(int a, int b, int c)
{
b = b;
foo(5, 6, 7, 8, 9);
a = a;
}
int main(int argc, char **argv)
{
bar(1,2,3);
return 0;
}
tausq@hiauly3:~$ gcc -g -o dwarfbug dwarfbug.c
tausq@hiauly3:~$ src/build64/gdb/gdb ./dwarfbug
GNU gdb 6.3.50.20051115-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa64-hp-hpux11.11"...
(gdb) b foo
Breakpoint 1 at 0x4000000000002418: file dwarfbug.c, line 4.
(gdb) run
Starting program: /home/tausq/dwarfbug
Breakpoint 1, foo (a=5, b=6, c=7, d=8, e=9) at dwarfbug.c:4
4 }
(gdb) bt
#0 foo (a=5, b=6, c=7, d=8, e=9) at dwarfbug.c:4
#1 0x4000000000002474 in bar (a=5, b=6, c=7) at dwarfbug.c:9
#2 0x40000000000024d0 in main (argc=5, argv=0x6) at dwarfbug.c:15
(gdb) quit
The program is running. Exit anyway? (y or n) y
Assembly and readelf -wi output attached.
randolph
[-- Attachment #2: dwarfbug.s --]
[-- Type: text/plain, Size: 5706 bytes --]
.LEVEL 2.0w
.file "dwarfbug.c"
.version "01.01"
.file 1 "dwarfbug.c"
.section .debug_abbrev,"",@progbits
L$debug_abbrev0000
.section .debug_info,"",@progbits
L$debug_info0000
.section .debug_line,"",@progbits
L$debug_line0000
.text
L$text0000
.align 8
.globl foo
.type foo, @function
L$FB0003
.loc 1 2 0
foo
.PROC
.CALLINFO FRAME=80,NO_CALLS,SAVE_SP,ENTRY_GR=3
.ENTRY
copy %r3,%r1
copy %r30,%r3
std,ma %r1,80(%r30)
std %r3,-8(%r30)
ldo -64(%r29),%r19
stw %r26,4(%r19)
stw %r25,12(%r19)
stw %r24,20(%r19)
stw %r23,28(%r19)
stw %r22,36(%r19)
.loc 1 4 0
ldo 64(%r3),%r30
ldd,mb -64(%r30),%r3
bve,n (%r2)
.EXIT
.PROCEND
L$FE0003
.size foo, .-foo
.align 8
.globl bar
.type bar, @function
L$FB0005
.loc 1 7 0
bar
.PROC
.CALLINFO FRAME=144,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4
.ENTRY
std %r2,-16(%r30)
copy %r3,%r1
copy %r30,%r3
std,ma %r1,144(%r30)
std %r3,-8(%r30)
std %r4,16(%r3)
ldo -64(%r29),%r19
stw %r26,4(%r19)
stw %r25,12(%r19)
stw %r24,20(%r19)
.loc 1 9 0
ldi 5,%r26
ldi 6,%r25
ldi 7,%r24
ldi 8,%r23
ldi 9,%r22
ldo -48(%r30),%r29
copy %r27,%r4
b,l foo,%r2
nop
copy %r4,%r27
.loc 1 11 0
ldd -16(%r3),%r2
ldd 16(%r3),%r4
ldo 64(%r3),%r30
ldd,mb -64(%r30),%r3
bve,n (%r2)
.EXIT
.PROCEND
L$FE0005
.size bar, .-bar
.align 8
.globl main
.type main, @function
L$FB0007
.loc 1 14 0
main
.PROC
.CALLINFO FRAME=144,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4
.ENTRY
std %r2,-16(%r30)
copy %r3,%r1
copy %r30,%r3
std,ma %r1,144(%r30)
std %r3,-8(%r30)
std %r4,16(%r3)
ldo -64(%r29),%r19
stw %r26,4(%r19)
std %r25,8(%r19)
.loc 1 15 0
ldi 1,%r26
ldi 2,%r25
ldi 3,%r24
ldo -48(%r30),%r29
copy %r27,%r4
b,l bar,%r2
nop
copy %r4,%r27
.loc 1 16 0
ldi 0,%r19
.loc 1 17 0
copy %r19,%r28
ldd -16(%r3),%r2
ldd 16(%r3),%r4
ldo 64(%r3),%r30
ldd,mb -64(%r30),%r3
bve,n (%r2)
.EXIT
.PROCEND
L$FE0007
.size main, .-main
L$etext0000
.section .debug_info
.word 0x155
.half 0x2
.word L$debug_abbrev0000
.byte 0x8
.uleb128 0x1
.word L$debug_line0000
.dword L$etext0000
.dword L$text0000
.stringz "dwarfbug.c"
.stringz "/home/tausq"
.stringz "GNU C 3.3.4 20040423 (prerelease)"
.byte 0x1
.uleb128 0x2
.word 0xb6
.byte 0x1
.stringz "foo"
.byte 0x1
.byte 0x2
.byte 0x1
.dword L$FB0003
.dword L$FE0003
.byte 0x1
.byte 0x53
.uleb128 0x3
.stringz "a"
.byte 0x1
.byte 0x1
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 4
.uleb128 0x3
.stringz "b"
.byte 0x1
.byte 0x1
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 12
.uleb128 0x3
.stringz "c"
.byte 0x1
.byte 0x1
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 20
.uleb128 0x3
.stringz "d"
.byte 0x1
.byte 0x1
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 28
.uleb128 0x3
.stringz "e"
.byte 0x1
.byte 0x1
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 36
.byte 0x0
.uleb128 0x4
.stringz "int"
.byte 0x4
.byte 0x5
.uleb128 0x2
.word 0x101
.byte 0x1
.stringz "bar"
.byte 0x1
.byte 0x7
.byte 0x1
.dword L$FB0005
.dword L$FE0005
.byte 0x1
.byte 0x53
.uleb128 0x3
.stringz "a"
.byte 0x1
.byte 0x6
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 4
.uleb128 0x3
.stringz "b"
.byte 0x1
.byte 0x6
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 12
.uleb128 0x3
.stringz "c"
.byte 0x1
.byte 0x6
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 20
.byte 0x0
.uleb128 0x5
.word 0x144
.byte 0x1
.stringz "main"
.byte 0x1
.byte 0xe
.byte 0x1
.word 0xb6
.dword L$FB0007
.dword L$FE0007
.byte 0x1
.byte 0x53
.uleb128 0x3
.stringz "argc"
.byte 0x1
.byte 0xd
.word 0xb6
.byte 0x2
.byte 0x83
.sleb128 4
.uleb128 0x3
.stringz "argv"
.byte 0x1
.byte 0xd
.word 0x144
.byte 0x2
.byte 0x83
.sleb128 8
.byte 0x0
.uleb128 0x6
.byte 0x8
.word 0x14a
.uleb128 0x6
.byte 0x8
.word 0x150
.uleb128 0x4
.stringz "char"
.byte 0x1
.byte 0x6
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x10
.uleb128 0x6
.uleb128 0x12
.uleb128 0x1
.uleb128 0x11
.uleb128 0x1
.uleb128 0x3
.uleb128 0x8
.uleb128 0x1b
.uleb128 0x8
.uleb128 0x25
.uleb128 0x8
.uleb128 0x13
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0xc
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x5
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0x24
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x2e
.byte 0x1
.uleb128 0x1
.uleb128 0x13
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0xc
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x6
.uleb128 0xf
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.word 0x27
.half 0x2
.word L$debug_info0000
.word 0x159
.word 0x5a
.stringz "foo"
.word 0xbd
.stringz "bar"
.word 0x101
.stringz "main"
.word 0x0
.section .debug_aranges,"",@progbits
.word 0x2c
.half 0x2
.word L$debug_info0000
.byte 0x8
.byte 0x0
.half 0x0
.half 0x0
.dword L$text0000
.dword L$etext0000-L$text0000
.dword 0x0
.dword 0x0
.ident "GCC: (GNU) 3.3.4 20040423 (prerelease)"
[-- Attachment #3: dwarfbug.txt --]
[-- Type: text/plain, Size: 4460 bytes --]
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length: 341
Version: 2
Abbrev Offset: 0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_stmt_list : 0
DW_AT_high_pc : 0x40000000000024f0
DW_AT_low_pc : 0x40000000000023f0
DW_AT_name : dwarfbug.c
DW_AT_comp_dir : /home/tausq
DW_AT_producer : GNU C 3.3.4 20040423 (prerelease)
DW_AT_language : 1 (ANSI C)
<1><5a>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_sibling : <b6>
DW_AT_external : 1
DW_AT_name : foo
DW_AT_decl_file : 1
DW_AT_decl_line : 2
DW_AT_prototyped : 1
DW_AT_low_pc : 0x40000000000023f0
DW_AT_high_pc : 0x4000000000002424
DW_AT_frame_base : 1 byte block: 53 (DW_OP_reg3)
<2><79>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : a
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 4 (DW_OP_breg19: 4)
<2><85>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : b
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 c (DW_OP_breg19: 12)
<2><91>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : c
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 14 (DW_OP_breg19: 20)
<2><9d>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : d
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 1c (DW_OP_breg19: 28)
<2><a9>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : e
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 24 (DW_OP_breg19: 36)
<1><b6>: Abbrev Number: 4 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
<1><bd>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_sibling : <101>
DW_AT_external : 1
DW_AT_name : bar
DW_AT_decl_file : 1
DW_AT_decl_line : 7
DW_AT_prototyped : 1
DW_AT_low_pc : 0x4000000000002428
DW_AT_high_pc : 0x400000000000248c
DW_AT_frame_base : 1 byte block: 53 (DW_OP_reg3)
<2><dc>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : a
DW_AT_decl_file : 1
DW_AT_decl_line : 6
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 4 (DW_OP_breg19: 4)
<2><e8>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : b
DW_AT_decl_file : 1
DW_AT_decl_line : 6
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 c (DW_OP_breg19: 12)
<2><f4>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : c
DW_AT_decl_file : 1
DW_AT_decl_line : 6
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 14 (DW_OP_breg19: 20)
<1><101>: Abbrev Number: 5 (DW_TAG_subprogram)
DW_AT_sibling : <144>
DW_AT_external : 1
DW_AT_name : main
DW_AT_decl_file : 1
DW_AT_decl_line : 14
DW_AT_prototyped : 1
DW_AT_type : <b6>
DW_AT_low_pc : 0x4000000000002490
DW_AT_high_pc : 0x40000000000024f0
DW_AT_frame_base : 1 byte block: 53 (DW_OP_reg3)
<2><125>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : argc
DW_AT_decl_file : 1
DW_AT_decl_line : 13
DW_AT_type : <b6>
DW_AT_location : 2 byte block: 83 4 (DW_OP_breg19: 4)
<2><134>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : argv
DW_AT_decl_file : 1
DW_AT_decl_line : 13
DW_AT_type : <144>
DW_AT_location : 2 byte block: 83 8 (DW_OP_breg19: 8)
<1><144>: Abbrev Number: 6 (DW_TAG_pointer_type)
DW_AT_byte_size : 8
DW_AT_type : <14a>
<1><14a>: Abbrev Number: 6 (DW_TAG_pointer_type)
DW_AT_byte_size : 8
DW_AT_type : <150>
<1><150>: Abbrev Number: 4 (DW_TAG_base_type)
DW_AT_name : char
DW_AT_byte_size : 1
DW_AT_encoding : 6 (signed char)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-22 0:07 ` Randolph Chung
@ 2005-11-22 5:15 ` Jim Blandy
2005-11-22 6:39 ` Randolph Chung
0 siblings, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2005-11-22 5:15 UTC (permalink / raw)
To: Randolph Chung; +Cc: Daniel Jacobowitz, gdb
A side point: you posted the readelf -wi output, so it doesn't matter
here, but for future reference, if you pass GCC the '-dA' flag when
you ask it to generate assembly-language output, GCC will include
comments alongside the Dwarf info that make it pretty legible. That
matters more in cases where the assembler is a suspect, of course.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Argument pointers, dwarf and prologue analysis
2005-11-22 5:15 ` Jim Blandy
@ 2005-11-22 6:39 ` Randolph Chung
0 siblings, 0 replies; 9+ messages in thread
From: Randolph Chung @ 2005-11-22 6:39 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb
Jim Blandy wrote:
> A side point: you posted the readelf -wi output, so it doesn't matter
> here, but for future reference, if you pass GCC the '-dA' flag when
> you ask it to generate assembly-language output, GCC will include
> comments alongside the Dwarf info that make it pretty legible. That
> matters more in cases where the assembler is a suspect, of course.
Thanks, I remember it was possible to do it with gcc but couldn't
remember the switch and didn't see it in a quick grep of the manpage.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-11-22 6:39 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-21 5:50 Argument pointers, dwarf and prologue analysis Randolph Chung
2005-11-21 7:42 ` Jim Blandy
2005-11-21 10:32 ` Randolph Chung
2005-11-21 14:08 ` Daniel Jacobowitz
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
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).