Re: -g broken for DWARF2 on x86 platforms

Re: -g broken for DWARF2 on x86 platforms

[Jeffrey A Law]

  In message < 19971125160134.55448@sco.com >you write:
  > I think it would be more constructive if we could actually look at
  > solving the problem, rather than bickering about what option invokes it.
Yes.  And I've actually spent some time working on it.  I believe the
problem is related to dwarfout's handling of arrays, but my feebile
hacks didn't fix the problem.  I just don't understand the code well enough
to fully analyze and solve the problem.

  > It cant be that hard to find, its a relatively new bug, and there are
  > no ChangeLog entries recently to dwarfout.c which could have had this
  > effect.
Actually, I kinda thing this is a long standing latent bug, assuming the
analysis I've done to date is correct.

jeff

Re: -g broken for DWARF2 on x86 platforms

[J. Kean Johnston]

On Tue, Nov 25, 1997 at 04:09:26PM -0800, Jeffrey A Law wrote:
> Yes.  And I've actually spent some time working on it.  I believe the
> problem is related to dwarfout's handling of arrays, but my feebile
> hacks didn't fix the problem.  I just don't understand the code well enough
> to fully analyze and solve the problem.
If there is anything I can do to help, please let me know. I am at your
disposal. I obviously have a vested interest in seeing Open Server
supported when gcc & egcs ship :-)

JKJ

Re: -g broken for DWARF2 on x86 platforms

[J. Kean Johnston]

On Tue, Nov 25, 1997 at 05:23:58PM -0500, Richard Kenner wrote:
>     There can be many reasonable alternatives to fix the current confusing
>     option names; they should be fixed in some reasonable way.  It is ok
>     to use minor issues like the one above to choose which reasonable way.
>     Just as long as they don't stand in the way of solving the problem at
>     all.
> 
> Jason has sent me a patch that I beleive will fix this and I'll
> install it once I take a closer look at it.

I think it would be more constructive if we could actually look at
solving the problem, rather than bickering about what option invokes it.
Can ANYONE point me in the direction of where to look? Has anyone else
looked at it? Does anyone on the EGCS mailing list know of a solution?
It cant be that hard to find, its a relatively new bug, and there are
no ChangeLog entries recently to dwarfout.c which could have had this
effect.

To any who dont know the problem, gcc -g (both FSF & egcs) both produce
bad labels when using DWARF debugging. Compiling gets you things like:
.L_T7012 unresolved symbol.  The assembler output shows a reference to
this, sure enough, but the label is never declared.

Re: -g broken for DWARF2 on x86 platforms

[Jason Merrill]

>>>>> J Kean Johnston <jkj@sco.com> writes:

> I think it would be more constructive if we could actually look at
> solving the problem, rather than bickering about what option invokes it.

Try this:

Tue Nov 25 22:43:30 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* dwarfout.c (output_type): If finalizing, write out nested types 
	of types we've already written.

Index: dwarfout.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/dwarfout.c,v
retrieving revision 1.73
diff -c -r1.73 dwarfout.c
*** dwarfout.c	1997/11/12 17:12:21	1.73
--- dwarfout.c	1997/11/26 06:45:02
***************
*** 4208,4214 ****
    type = type_main_variant (type);
  
    if (TREE_ASM_WRITTEN (type))
!     return;
  
    /* If this is a nested type whose containing class hasn't been
       written out yet, writing it out will cover this one, too.  */
--- 4208,4229 ----
    type = type_main_variant (type);
  
    if (TREE_ASM_WRITTEN (type))
!     {
!       if (finalizing && AGGREGATE_TYPE_P (type))
! 	{
! 	  register tree member;
! 
! 	  /* Some of our nested types might not have been defined when we
! 	     were written out before; force them out now.  */
! 
! 	  for (member = TYPE_FIELDS (type); member;
! 	       member = TREE_CHAIN (member))
! 	    if (TREE_CODE (member) == TYPE_DECL
! 		&& ! TREE_ASM_WRITTEN (TREE_TYPE (member)))
! 	      output_type (TREE_TYPE (member), containing_scope);
! 	}
!       return;
!     }
  
    /* If this is a nested type whose containing class hasn't been
       written out yet, writing it out will cover this one, too.  */

Re: -g broken for DWARF2 on x86 platforms

[Robert Lipe]

> Tue Nov 25 22:43:30 1997  Jason Merrill  <jason@yorick.cygnus.com>
> 
> 	* dwarfout.c (output_type): If finalizing, write out nested types 
> 	of types we've already written.

I don't know if it really, really does the right right thing (i.e. I
didn't test that a debugger can read the output) but applying this
patch and performing a 'make bootstrap3' on the most recent egcs
snapshot does allow the libio and libstdc++ tests to run to (largely) 
successful completion on i586-pc-sco3.2v5.0.4 in ELF mode which uses
dwarf.

Thanx much, Jason!

RJL

Re: -g broken for DWARF2 on x86 platforms

[Richard Stallman]

    -gdwarf2 produces DWARF 1 output (debug level 2).
    -gdwarf-2 produces DWARF 2 output.

That looks like a confusing set of options!  I am sure there is logic
behind it, but nonetheless I think we should look for an alternative
set of names which avoids the ambiguity.

Perhaps we could use -gxdwarf to mean dwarf 2 ("extended dwarf").

Re: -g broken for DWARF2 on x86 platforms

[Jeffrey A Law]

  In message < u9pvnqiyyr.fsf@yorick.cygnus.com >you write:
  > >>>>> J Kean Johnston <jkj@sco.com> writes:
  > 
  > > Compiling C++ stuff with -g is broken on any platform with uses (or can
  > > use) DWARF or DWARF2.  Both on SCO and Linux dwarf2 -g causes unknown
  > > symbols (for example .L_T6310) to be output.
  > 
  > -gdwarf2 produces DWARF 1 output (debug level 2).
  > -gdwarf-2 produces DWARF 2 output.
  > The undefined symbol bug appears only to affect dwarf 1.
Good point.

I think I know what the problem is:

We never call equate_type_number_to_die_number for the type of array
elements.

You might think that the call in output_array_type_die would handle this,
but if you look closely at the loop in subscripe_data_attribute it can
change TYPE before calling type_attribute for the array element type.

Jeff

Re: -g broken for DWARF2 on x86 platforms

[Jason Merrill]

>>>>> J Kean Johnston <jkj@sco.com> writes:

> Compiling C++ stuff with -g is broken on any platform with uses (or can
> use) DWARF or DWARF2.  Both on SCO and Linux dwarf2 -g causes unknown
> symbols (for example .L_T6310) to be output.

-gdwarf2 produces DWARF 1 output (debug level 2).
-gdwarf-2 produces DWARF 2 output.
The undefined symbol bug appears only to affect dwarf 1.

Jason

Re: -g broken for DWARF2 on x86 platforms

[Jeffrey A Law]

  In message < u9pvnqiyyr.fsf@yorick.cygnus.com >you write:
  > >>>>> J Kean Johnston <jkj@sco.com> writes:
  > 
  > > Compiling C++ stuff with -g is broken on any platform with uses (or can
  > > use) DWARF or DWARF2.  Both on SCO and Linux dwarf2 -g causes unknown
  > > symbols (for example .L_T6310) to be output.
  > 
  > -gdwarf2 produces DWARF 1 output (debug level 2).
  > -gdwarf-2 produces DWARF 2 output.
  > The undefined symbol bug appears only to affect dwarf 1.
Well, my guess wasn't correct.  Though I think it's close.  Someone who
knows more about dwarf will have to look at it.

Basically I'd concentrate on the array element code, that's what's creating
the reference to an undefined label.

jeff