Assembling pending decls before writing their debug info

Assembling pending decls before writing their debug info

[Nick Clifton]

Hi Guys,

  There is a problem with unit-at-a-time compilation and DWARF debug
  info generation.  Consider this small test case which has been
  derived from GDB's observer.c source file:

    int observer_test_first_observer = 0;
    int observer_test_second_observer = 0;
    int observer_test_third_observer = 0;

    void observer_test_first_notification_function (void)
    {
      observer_test_first_observer++;
    }

    void observer_test_second_notification_function (void)
    {
      observer_test_second_observer++;
    }

    void observer_test_third_notification_function (void)
    {
      observer_test_third_observer++;
    }

  When compiled with the current mainline gcc sources for an x86
  native target and with "-g -O2 -dA" on the command line the
  following debug info is produced:

            [snip]
	.long	.LASF0	# DW_AT_name: "observer_test_first_observer"
	.byte	0x1	# DW_AT_decl_file
	.byte	0x1	# DW_AT_decl_line
	.long	0x37	# DW_AT_type
	.byte	0x1	# DW_AT_external
	.byte	0x5	# DW_AT_location
	.byte	0x3	# DW_OP_addr
	.long	observer_test_first_observer
	.uleb128 0x3	# (DIE (0x37) DW_TAG_base_type)
	.ascii "int\0"	# DW_AT_name
	.byte	0x4	# DW_AT_byte_size
	.byte	0x5	# DW_AT_encoding
	.uleb128 0x4	# (DIE (0x3e) DW_TAG_variable)
	.long	.LASF1	# DW_AT_name: "observer_test_second_observer"
	.byte	0x1	# DW_AT_decl_file
	.byte	0x2	# DW_AT_decl_line
	.long	0x37	# DW_AT_type
	.byte	0x1	# DW_AT_external
	.byte	0x0	# DW_AT_const_value
            [snip]

  Note how observer_test_first_observer is correctly defined as having
  a DW_AT_location and a DW_OP_addr whereas
  observer_test_second_observer is incorrectly defined as having a
  DW_AT_const_value.  ie the debug info is saying that it is a
  variable without a location in memory.

  The reason for this behaviour is that the debug information is being
  written out before the variables have been fully resolved.  In
  particular DECL_SET() for the second and third observer functions is
  NULL when the debug info is generated, which is why they are being
  given the DW_AT_const_value attribute.
  
  In trying to solve this I found that switching the order of the
  calls to lang_hooks.decls.final_write_globals() and 
  cgraph_varpool_assemble_pending_decls() in compile_file() worked,
  and this seemed to be intuitively correct.  But when I reran the gcc
  testsuite I found that the change introduced a regression:
  gcc.dg/varpool-1.c now had the variable
  "unnecessary_static_initialized_variable" still defined at the end
  of compilation.

  I have investigated some more but not gotten much further, so I am
  asking for help.  Can anyone suggest where the conflict between
  generating the debug info and deciding if the variable is going to
  be emitted should really be resolved ?

Cheers
  Nick
  

Re: Assembling pending decls before writing their debug info

[Andrew Pinski]

> 
> Hi Guys,
> 
>   There is a problem with unit-at-a-time compilation and DWARF debug
>   info generation.  Consider this small test case which has been
>   derived from GDB's observer.c source file:

There was even more issues with uninitialized variables a month ago.
This was all caused by Mark's patch to fix PR 18556.
This is a regression from 3.4.x.

Thanks,
Andrew Pinski

Re: Assembling pending decls before writing their debug info

[James E Wilson]

Nick Clifton wrote:
>   The reason for this behaviour is that the debug information is being
>   written out before the variables have been fully resolved.  In
>   particular DECL_SET() for the second and third observer functions is
>   NULL when the debug info is generated, which is why they are being
>   given the DW_AT_const_value attribute.

See PR 21828 where some possible solutions for a related problem got
discussed.  Eventually, PR 21828 was fixed when Richard Henderson fixed
something else and Mark Mitchell's patch for PR 18556 got reverted.
This is discussed in the log.

Meanwhile, there have been reports of some other related problems.
There is a report from Apple near the end of PR 21828 that mentions
stabs is still broken.  This got rereported as PR 23190 and contains a
patch similar to ones discussed in PR 21828.

The interface between the front ends and cgraph really needs to be
worked out here.  Currently, the C and C++ front ends are calling some
cgraph functions in different orders, and we are having lots of debug
related problems.

Maybe we need to move the calls to the debugging hooks from toplev into
cgraph, so that they are only called when a variable is finalized?  The
right place to do this seems to be cgraph_varpool_assemble_pending_decls
where it calls assemble_variable.  And there is already a debug info
hook there, but it is only used for static variables.  So we need to get
debug info for global variables emitted here, rather than in
check_global_decls in toplev.c.  You will need some magic variable to
test in check_global_decls to prevent duplicate debug info, perhaps
making the debug hook call here dependent on !flag_unit_at_a_time will work?
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Assembling pending decls before writing their debug info

[Daniel Berlin]

On Wed, 2005-08-24 at 12:33 -0700, James E Wilson wrote:
> Nick Clifton wrote:
> >   The reason for this behaviour is that the debug information is being
> >   written out before the variables have been fully resolved.  In
> >   particular DECL_SET() for the second and third observer functions is
> >   NULL when the debug info is generated, which is why they are being
> >   given the DW_AT_const_value attribute.
> 
> See PR 21828 where some possible solutions for a related problem got
> discussed.  Eventually, PR 21828 was fixed when Richard Henderson fixed
> something else and Mark Mitchell's patch for PR 18556 got reverted.
> This is discussed in the log.
> 
> Meanwhile, there have been reports of some other related problems.
> There is a report from Apple near the end of PR 21828 that mentions
> stabs is still broken.  This got rereported as PR 23190 and contains a
> patch similar to ones discussed in PR 21828.
> 
> The interface between the front ends and cgraph really needs to be
> worked out here.  Currently, the C and C++ front ends are calling some
> cgraph functions in different orders, and we are having lots of debug
> related problems.
> 
> Maybe we need to move the calls to the debugging hooks from toplev into
> cgraph, so that they are only called when a variable is finalized? 

This is something i meant to do for 4.1, but didn't get to :(

At this point, cgraph should definitely be driving the debug output, at
least for the variables it knows about.
IMHO. :)

The blocker last time i looked was that we had to support
non-unit-at-a-time, and thus, it wasn't at all clear to me what logic i
could remove completely, and what logic needed to be !
flag_unit_at_a_time.

Re: Assembling pending decls before writing their debug info

[Tom Tromey]

>>>>> "Jim" == James E Wilson <wilson@specifix.com> writes:

Jim> The interface between the front ends and cgraph really needs to be
Jim> worked out here.  Currently, the C and C++ front ends are calling some
Jim> cgraph functions in different orders, and we are having lots of debug
Jim> related problems.

Let me enter a plea for more documentation.  For gcjx I only found out
about the cgraph functions by happenstance.  And it was far from clear
what should be called when -- I kind of duplicated what gcj did, but I
really have no idea if it is correct.  About the best I can say is
that it seems to work.

Tom