List Info

Thread: GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?




GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
user name
2006-04-05 06:25:58
[moved from gccgnu.org]

 > > 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.
 > 
 > That's a bug in GDB, and not hard to fix.  You're
welcome to do it, or
 > to file it in GNATS 

Is it easy?  With the optimisation GDB thinks argc is
LOC_STATIC, which is why
it tries to print its value with the "info
locals" command, even though it is
not a local variable in GDB's usual sense.  The only way I
can think of doing
thi is testing if sym->ginfo.name is "argc"
or "argv" in the LOC_STATIC case of
the switch statements of print_block_frame_locals and
list_args_or_locals.
Its inelegant and probably not general either.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob
GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
user name
2006-04-05 13:36:38
On Wed, Apr 05, 2006 at 06:25:58PM +1200, Nick Roberts
wrote:
>  > > 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.
>  > 
>  > That's a bug in GDB, and not hard to fix. 
You're welcome to do it, or
>  > to file it in GNATS 
> 
> Is it easy?  With the optimisation GDB thinks argc is
LOC_STATIC, which is why
> it tries to print its value with the "info
locals" command, even though it is
> not a local variable in GDB's usual sense.

Well, there are at least three bugs here.  First, it should
be printed
in "info args" instead of "info
locals".  Secondly, failure to access
it should not be fatal.  Third, it's not really LOC_STATIC.

The third is the easiest to fix.  I assume the reason that
it is
assigned LOC_STATIC is in new_symbol, where we check for
DW_AT_external?  In that branch, if there is no external
flag, we could
change the LOC_STATIC to LOC_OPTIMIZED_OUT. That should get
you an
<optimized out> instead of an error at address 0x0.

Fixing "info args" would be a matter of either
adding yet another LOC_
value, which I don't think is a good idea, or moving the
is-this-an-argument check out of the LOC_* value.  Having
both
LOC_COMPUTED and LOC_COMPUTED_ARG has always been a bit of a
hack.
There could be a flag somewhere instead.  But, this would
require
changing a bunch of switch statements in various places.

And for the fatal access, it might be possible to add an
appropriate
check in value_check_printable to print something like
<invalid
address> (already used by the C++ code).  That would fix
both the CLI
command and the MI command.

>  The only way I can think of doing
> thi is testing if sym->ginfo.name is
"argc" or "argv" in the LOC_STATIC
case of
> the switch statements of print_block_frame_locals and
list_args_or_locals.
> Its inelegant and probably not general either.

Heck no!  This has nothing to do with argc or argv, and
everything to
do with unused arguments.

-- 
Daniel Jacobowitz
CodeSourcery
GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
user name
2006-04-06 23:54:44
 > > Is it easy?  With the optimisation GDB thinks
argc is LOC_STATIC, which
 > > is why it tries to print its value with the
"info locals" command, even
 > > though it is not a local variable in GDB's usual
sense.
 > 
 > Well, there are at least three bugs here.  First, it
should be printed
 > in "info args" instead of "info
locals".  Secondly, failure to access
 > it should not be fatal.  Third, it's not really
LOC_STATIC.
 > 
 > The third is the easiest to fix.  I assume the reason
that it is
 > assigned LOC_STATIC is in new_symbol, where we check
for
 > DW_AT_external?  In that branch, if there is no
external flag, we could
 > change the LOC_STATIC to LOC_OPTIMIZED_OUT. That
should get you an
 > <optimized out> instead of an error at address
0x0.

OK, I've changed the default value in new_symbol from
LOC_STATIC to
LOC_OPTIMIZED_OUT.  This means "info locals"
works as expected.  The
command "info args" still gives "No
arguments." when the arguments are
not used and they've been optimised out.  I've also
checked that a static
variable is correctly identified as LOC_STATIC and that no
new fails are
introduced into the testsuite.

I guess it still might break something else though, so how
about applying
this patch after the next release so it gets a bit of
testing first?


-- 
Nick                                           http://www.inet.net.n
z/~nickrob


2006-04-07  Nick Roberts  <nickrobsnap.net.nz>

	* dwarf2read.c (new_symbol): Make LOC_OPTIMIZED_OUT the
default
	value for a symbol.


*** dwarf2read.c	31 Mar 2006 12:46:15 +1200	1.193
--- dwarf2read.c	06 Apr 2006 10:11:22 +1200	
***************
*** 6853,6859 ****
        /* Default assumptions.
           Use the passed type or decode it from the die. 
*/
        SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
!       SYMBOL_CLASS (sym) = LOC_STATIC;
        if (type != NULL)
  	SYMBOL_TYPE (sym) = type;
        else
--- 6853,6859 ----
        /* Default assumptions.
           Use the passed type or decode it from the die. 
*/
        SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
!       SYMBOL_CLASS (sym) = LOC_OPTIMIZED_OUT;
        if (type != NULL)
  	SYMBOL_TYPE (sym) = type;
        else
GCC 4.1.0 doesn't generate DWARF 2 output for function arguments?
user name
2006-05-05 15:55:06
On Fri, Apr 07, 2006 at 12:54:44AM +0100, Nick Roberts
wrote:
> OK, I've changed the default value in new_symbol from
LOC_STATIC to
> LOC_OPTIMIZED_OUT.  This means "info
locals" works as expected.  The
> command "info args" still gives "No
arguments." when the arguments are
> not used and they've been optimised out.  I've also
checked that a static
> variable is correctly identified as LOC_STATIC and that
no new fails are
> introduced into the testsuite.
> 
> I guess it still might break something else though, so
how about applying
> this patch after the next release so it gets a bit of
testing first?

Hi Nick,

I don't know when the next release is going to be; but I
don't think
there's much benefit in waiting.  Your patch looks right to
me.

> 2006-04-07  Nick Roberts  <nickrobsnap.net.nz>
> 
> 	* dwarf2read.c (new_symbol): Make LOC_OPTIMIZED_OUT
the default
> 	value for a symbol.

OK.

-- 
Daniel Jacobowitz
CodeSourcery
[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )