Re: debug/10000: gcc -g generates location expressions which are not valid in prologue

Re: debug/10000: gcc -g generates location expressions which are not valid in prologue

[Zack Weinberg]

The following reply was made to PR debug/10000; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: werner@almesberger.net
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/10000: gcc -g generates location expressions which are
 not valid in prologue
Date: Sat, 08 Mar 2003 10:26:46 -0800

 werner@almesberger.net writes:
 
 >>Number:         10000
 >>Category:       debug
 >>Synopsis:       gcc -g generates location expressions which are not
 >>                valid in prologue
 
 Congratulations! You filed bug report 10000 (a big, round number).
 
 More seriously, thank you for investigating all these flaws in gcc's
 DWARF2 output and posting detailed bug reports.
 
 zw

debug/10000: gcc -g generates location expressions which are not valid in prologue

[werner]

>Number:         10000
>Category:       debug
>Synopsis:       gcc -g generates location expressions which are not valid in prologue
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 08 14:16:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Werner Almesberger
>Release:        3.3 20030303 (prerelease)
>Organization:
>Environment:
System: Linux ar 2.4.18 #5 Mon Mar 18 09:25:24 ART 2002 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --prefix=/usr/local/gcc20030303/ --enable-languages=c
>Description:

gcc -g generates location expressions which are not valid
in prologue

This may actually be more a misfeature of DWARF2 than a gcc bug.
Theoretically, DWARF2 would allow us to express exactly what is
valid and at which location, even during the prologue, but this
seems to be quite cumbersome.

>How-To-Repeat:

Example (with Red Hat's gcc 3.1 20011127 on ia32):

$ cat <<EOF >foo.c
int main(int argc)
{
    return 0;
}
EOF
$ gcc -g foo.c
$ readelf -w a.out
...
     DW_AT_name        : (indirect string, offset: 0x3f): main
...
     DW_AT_low_pc      : 0x8048398 134513560
...
     DW_AT_frame_base  : 1 byte block: 55       (DW_OP_reg5; )
 <2><40>: Abbrev Number: 3 (DW_TAG_formal_parameter)
     DW_AT_name        : (indirect string, offset: 0x3a): argc
...
     DW_AT_location    : 2 byte block: 91 8     (DW_OP_fbreg: 8; )
...
$ objdump -d a.out
...
08048398 <main>:
 8048398:       55                      push   %ebp
 8048399:       89 e5                   mov    %esp,%ebp
 804839b:       83 ec 08                sub    $0x8,%esp
 804839e:       83 e4 f0                and    $0xfffffff0,%esp
...

Quite obviously, 8(%ebp) only points to argc when we've reached
address 804839b, but the debugging information does not provide
any indication more precise than DW_AT_low_pc.

>Fix:

The work-around gdb uses seems to work reasonably well, but I'm
a bit worried about whether unusual linkage styles might throw
it off. (After all, this has to work with the Linux kernel.)
>Release-Note:
>Audit-Trail:
>Unformatted: