GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
program below I get results which didn't occur before (Fedora Core 3). I
posted them to [EMAIL PROTECTED] but I think something is up with GCC
4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These
results are with DWARF 2. GCC 4.1.0 with stabs worked as expected
Nick http://www.inet.net.nz/~nickrob
/* -*- compile-command: "cc -g -o simple simple.c"; -*- */
main(int argc, char **argv) {
int i;
i = 1;
}
After starting execution and breaking at main:
With gcc --version
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk)
(gdb) info args
argc = 1
argv = (char **) 0xb7a4
With gcc --version
gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
(gdb) info args
No arguments.
readelf -wi simple (for GCC 3.2) gives (about 1200 lines of output):
...
<2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: (indirect string, offset: 0x98e): argc
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
DW_AT_location: 2 byte block: 91 8 (DW_OP_fbreg: 8; )
<2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: (indirect string, offset: 0x993): argv
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
DW_AT_location: 2 byte block: 91 c (DW_OP_fbreg: 12; )
<2>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_name: i
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type:
DW_AT_location: 2 byte block: 91 7c(DW_OP_fbreg: -4; )
...
readelf -wi simple (for GCC 4.1.0) gives (about 60 lines of output):
...
<2><75>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type: <9a>
<2><81>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_type:
<2><8d>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_name: i
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type: <9a>
DW_AT_location: 2 byte block: 91 70(DW_OP_fbreg: -16)
...
Re: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
> They've been optimized away. Not surprising, since they are unused, > although slightly surprising that it happened with -O0. The manual says: `-O0' Do not optimize. This is the default. so that seems to be a documentation bug at least. More generally, it seems odd to force an optimization on a user that he might not want. Its interesting that a quote on Bugzilla says that debugging is twice as hard as writing code. If thats the case, theres no point in making it any harder. It also causes GDB to generate errors on the output of other commands: (gdb) info locals argc = Cannot access memory at address 0x0 as well as the GDB/MI equivalent -stack-list-locals. This breaks the front end that I'm writing fo Emacs. I'm sure that GDB can be rewritten to overcome this but what other optimizations do/will GCC developers decide users must have? The above optimization seems just to save a few bytes unless a program is deeply nested. Why not reserve it for -O1 and higher? Nick http://www.inet.net.nz/~nickrob
Internals for STL containers
Emacs 22.1 has a graphical interface to Gdb which allows the display of
watch expressions in the Speedbar.
Using variable objects, if I display a watch expression for an STL container
in a program compiled with gcc, e.g.,
vector v (3);
v[0] = 1;
v[1] = 11;
v[2] = 22;
in the Speedbar, I get something like this:
v std::vector >
std::_Vector_base >
std::_Vector_base >
public
_M_impl std::_Vector_base >::_Vector_impl
std::allocator std::allocator
__gnu_cxx::new_allocator {...}
public
_M_start int * 0x804c008
*_M_start 0
_M_finishint * 0x804c014
*_M_finish135153
_M_end_of_storageint * 0x804c014
*_M_end_of_storage135153
which is a bit meaningless to the end user. In this case, I know where the
values are really stored:
v._M_impl._M_start int * 0x804c008
*v._M_impl._M_start1
*(v._M_impl._M_start+1)11
*(v._M_impl._M_start+2)22
(gdb) p v._M_impl._M_finish - v._M_impl._M_start
$1 = 3
and it would be better for Emacs to display some of these.
However, _M_impl, _M_start etc are gcc internals and it might be risky for
Emacs to rely on them. Can anyone say how likely these internals are to
change? I'm not asking for a guarantee. It would be helpful just to know
when they last changed as an indication of how volatile this code might be.
--
Nick http://www.inet.net.nz/~nickrob
Re: Internals for STL containers
> > I would say they are pretty stable, because we have a stable ABI which > > we are not going to break until C++0x: that means we can only implement > > limited span changes, we cannot add data members, for example neither > > change the memory layout of the classes. Probably an ignorant question, but how does this particular ABI get used? > Yes, it would certainly make sense to teach gdb (not just the Emacs > interface of gdb) to recognize STL containers and give a better display. > The members of std::vector have been stable since gcc-3.0, I'm pretty > sure (certainly since 3.2). I was thinking of doing it in Emacs, not Gdb. AFAIK, Gdb can't tell what compiler created the executable. > But that would be more appropriate to discuss on the gdb list. Yes, but are the internals of the STL containers described somewhere, the GCC internals manual, for example? -- Nick http://www.inet.net.nz/~nickrob
