Argument pointers, dwarf and prologue analysis

Argument pointers, dwarf and prologue analysis

[Randolph Chung]

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/

Re: Argument pointers, dwarf and prologue analysis

[Jim Blandy]

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.

Re: Argument pointers, dwarf and prologue analysis

[Randolph Chung]

> 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

Re: Argument pointers, dwarf and prologue analysis

[Daniel Jacobowitz]

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

Re: Argument pointers, dwarf and prologue analysis

[Randolph Chung]

> 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

Re: Argument pointers, dwarf and prologue analysis

[Daniel Jacobowitz]

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

Re: Argument pointers, dwarf and prologue analysis

[Randolph Chung]

[-- 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)

Re: Argument pointers, dwarf and prologue analysis

[Jim Blandy]

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.

Re: Argument pointers, dwarf and prologue analysis

[Randolph Chung]

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/