Re: dwarf2 debug dependent upon GAS?

Re: dwarf2 debug dependent upon GAS?

[Jim Wilson]

In article <19990221144644.M8783.cygnus.egcs@rjlhome.sco.com> you write:
>I've had it on my list to examine Dwarf2 debugging for System V.  I'm
>finding that it seems to depend upon a curiosity of the GNU assembler.
>Is this accurate?

It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
assemblers that I know about.

There are clear advantages to having a dwarf2 aware assembler when emitting
dwarf2 debug info.  There is only this one curiousity we need for correctness,
but there are a number of cases where special assembler support would give us
more compact debug info.  We currently don't take advantage of any GNU as
features for this yet, but I expect we will eventually.  This will mean that
we'll have smaller debug info if we use GNU as.

>I'm seeing EGCS (current trunk) generate refences to symbols that don't
>exist.  There are SECTIONS of that name, but no symbols.  Apparently
>GAS treat them interchangably.  Is it the intent for these to reference
>the beginning of the section in this file (i.e. local labels) or the
>beginning of that section once linked? (without making them global, I
>don't know how I would synthesize that.)

The latter, sort of.  The dwarf2 standard says that some fields are offsets
relative to the address of the final linked section.  This means that we can't
compute these offsets until link time.

You can get this effect by using a section name as a symbol name in GNU as
and SGI irix6 as.

If you don't have relocations and assembler syntax for this, then it will
be hard to synthesize it.  It might be possible to get the same effect
by creating a file that always gets linked first, and which contains special
labels to mark the start of each section, and then use label subtraction to
get an offset.  There are cases where this won't work, but I don't recall the
details.  I've discussed this before with other people and never found a
satisfactory solution.

There is some language in the MIPS processor supplement to the SVR4 ABI 
that seems to document this.  In the section Relocation, it defines a symbol
(S) relocation as
	Represents the value of the symbol whose index resides in the
	relocation entry, unless the symbol is STB_LOCAL and is of type
	STT_SECTION, in which case S represents the original sh_addr minus
	the final sh_addr.
and that gives the result that we want.  I haven't found similar language in
any other SVR4 ABI.  I don't know how this got into the MIPS SVR4 ABI.  This
is a 1990 copyright document, but dwarf2 didn't exist until several years
later, so it seems unlikely that it was added specifically for dwarf2.

If we can't get the exact result that the standard asks for, then perhaps
we can create a dwarf2-variant for dwarf2-unaware assemblers.  For instance,
substituting in an absolute address where the standard wants a section-relative
offset might make some of these problems go away.  This would require some
support in gdb for the dwarf2-variant though.

Jim

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

Hi, Jim.

Thanx for the reply.

> It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
> assemblers that I know about.

The native compiler and debugger on SVR5 munch dwarf2 by default.  I
don't know how aware of dwarf the assembler really is.

> The latter, sort of.  The dwarf2 standard says that some fields are offsets
> relative to the address of the final linked section.  This means that we can't
> compute these offsets until link time.

Is there some sort of tool that a human can use to help read these
tables?  I can examine the output of 'main(){}' compiled with a native
compiler using -g, but the tables are complex enough that I can't
readily parse them in my head to see how this issue is sidestepped on
the native tools.


I've asked the SCO tool dudes to offer hints.

Thanx,
RJL

Re: dwarf2 debug dependent upon GAS?

[Brian Ford]

On Mon, 22 Feb 1999, Robert Lipe wrote:

> Hi, Jim.
> 
> Thanx for the reply.
> 
> > It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
> > assemblers that I know about.
> 
> The native compiler and debugger on SVR5 munch dwarf2 by default.  I
> don't know how aware of dwarf the assembler really is.
> 
> > The latter, sort of.  The dwarf2 standard says that some fields are offsets
> > relative to the address of the final linked section.  This means that we can't
> > compute these offsets until link time.
> 
> Is there some sort of tool that a human can use to help read these
> tables?  I can examine the output of 'main(){}' compiled with a native
> compiler using -g, but the tables are complex enough that I can't
> readily parse them in my head to see how this issue is sidestepped on
> the native tools.
> 
I'm not exactly sure what you are asking for, but would dwarfdump do the
trick?

> 
> I've asked the SCO tool dudes to offer hints.
> 
> Thanx,
> RJL
> 

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

Brian Ford wrote:

> On Mon, 22 Feb 1999, Robert Lipe wrote:
>
> > Is there some sort of tool that a human can use to help read [dwarf]
> > tables?
>
> I'm not exactly sure what you are asking for, but would dwarfdump do
> the trick?

From the name, it sounds interesting.  Does dwarfdump exist outside of
the SGI/MIPS tool kit?

If it doesn't, it doesn't do me much good.

Re: dwarf2 debug dependent upon GAS?

[Brian Ford]

On Tue, 23 Feb 1999, Robert Lipe wrote:

> Brian Ford wrote:
> 
> > On Mon, 22 Feb 1999, Robert Lipe wrote:
> >
> > > Is there some sort of tool that a human can use to help read [dwarf]
> > > tables?
> >
> > I'm not exactly sure what you are asking for, but would dwarfdump do
> > the trick?
> 
> >From the name, it sounds interesting.  Does dwarfdump exist outside of
> the SGI/MIPS tool kit?
> 
> If it doesn't, it doesn't do me much good.
> 
> 
Sorry, I don't know.  Probably not, though.

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: dwarf2 debug dependent upon GAS?

[Jim Wilson]

irix6 has a program called dwarfdump which is very nice.  I don't know where
else it is available.  There has been some work on adding dwarf2 dumping to
the binutils readelf program.  You'd have to get a recent binutils snapshot
to try it though.  Using gcc -dA -S gives you readable commented assembler
files which might help.

Jim

Re: dwarf2 debug dependent upon GAS?

[Daniel Berlin]

> Brian Ford wrote:
>
> > On Mon, 22 Feb 1999, Robert Lipe wrote:
> >
> > > Is there some sort of tool that a human can use to help read [dwarf]
> > > tables?
> >
> > I'm not exactly sure what you are asking for, but would dwarfdump do
> > the trick?
>
> From the name, it sounds interesting.  Does dwarfdump exist outside of
> the SGI/MIPS tool kit?
>
> If it doesn't, it doesn't do me much good.
>
>

I have a dwarf2 dumper (more of a reader, it can dump it in a nicely
readable format as a side effect) written in python, which means it should
be portable just about anywhere.
It only works on ELF executables , but if you can give it the offsets of the
various debug sections, and such, it'll happily read them and process them.
The only thing it doesn't do right now is location expressions, because i
just haven't gotten around to it (it's rather easy, you just need to
describe the structure to it).
It's part of a debugger i wrote for BeOS.  I got tired of writing the dwarf2
reading/processing code in C++, it was just much easier in python, and
easier to maintain.  In addition to dumping the info, it also builds and
keeps track of a hashtable and a proper "general" tree of each compilation
unit, keyed on the offsets.
I also have a c module for the structure unpacker i wrote that it uses,
which makes it take 3 seconds to read and process large amount of debug info
(3 meg in this case), as opposed to 20 for the straight python code ( You
shouldn't run into alignment issues on the C code, as it was written with
avoiding them in mind. I could be wrong, however.)

Lemme know if you want it (or anyone else for that matter, just put "python
dwarf2 code" in the subject so it goes into the right folder)
Dan

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

 >> I'm seeing EGCS (current trunk) generate refences to symbols that don't
 >> exist.  There are SECTIONS of that name, but no symbols.  Apparently
 >> GAS treat them interchangably.  Is it the intent for these to reference
 >> the beginning of the section in this file (i.e. local labels) or the
 >> beginning of that section once linked? (without making them global, I
 >> don't know how I would synthesize that.)

 > The latter, sort of.  The dwarf2 standard says that some fields are
 > offsets relative to the address of the final linked section.  This means
 > that we can't compute these offsets until link time.

Actually, it's a lot simpler than that.  The references are not to the
beginning of the section in the executable, but to the offset from there to
the beginning of the info for the particular translation unit.  Since the
beginning of the section is at 0, this simplifies to the address of the
beginning of the section in question for the current translation unit.  In
GNU as, SGI as and Sun as, referring to a section name as a symbol gives us
that.  If SCO doesn't support this feature (which I assumed was standard
SVR4), it would be simple enough to emit some random symbol at the
beginning of the assembly output and refer to that instead.

Jason

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 > Our staff that was around at the time of the original SVR4 on 3B2
 > (remember, SCO bought The Organization Formerly Known As USL) says their
 > assembler/linker didn't do this.

OK.

 > What would be the best way to handle this?  Something like letting
 > ASM_OUTPUT_SECTION_NAME watch for the first time any of the 'debug_'
 > sections are emitted and then letting it emit a symbol of the same name?

Nah, just spit out the useful ones in dwarf2out_init.

 > The random symbol could be the section name, right?

I'd suggest a variant on the section name so we can use that solution for
all targets.

Jason

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

>  > What would be the best way to handle this?  Something like letting
>  > ASM_OUTPUT_SECTION_NAME watch for the first time any of the 'debug_'
>  > sections are emitted and then letting it emit a symbol of the same name?
> 
> Nah, just spit out the useful ones in dwarf2out_init.
> 
>  > The random symbol could be the section name, right?
> 
> I'd suggest a variant on the section name so we can use that solution for
> all targets.

This turned ugly.  In the process it became a spokesperson for use of
ANSI string pasting, but I know that's a no-no for us.

It does allow an empty C file to assemble and link on SVR5 when using
-gdwarf-2.  Still, it "feels" wrong.  Before I continue down this path,
can you please tell me if I should perhaps go a different way?

Thanx,
RJL




Index: dwarf2out.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/dwarf2out.c,v
retrieving revision 1.85
diff -u -p -r1.85 dwarf2out.c
--- dwarf2out.c	1999/02/24 17:48:42	1.85
+++ dwarf2out.c	1999/02/26 04:50:54
@@ -2613,6 +2613,7 @@ static unsigned lookup_filename		PROTO((
 #define STR_SECTION		".debug_str"
 #endif
 
+
 /* Standard ELF section names for compiled code and data.  */
 #ifndef TEXT_SECTION
 #define TEXT_SECTION		".text"
@@ -2624,6 +2625,16 @@ static unsigned lookup_filename		PROTO((
 #define BSS_SECTION		".bss"
 #endif
 
+dyn_string_t abbrev_section_base;
+dyn_string_t debug_line_section_base;
+dyn_string_t debug_info_section_base;
+dyn_string_t text_section_base;
+
+#define ABBREV_SECTION_BASE	ABBREV_SECTION "_base"
+#define DEBUG_LINE_SECTION_BASE	DEBUG_LINE_SECTION "_base"
+#define DEBUG_INFO_SECTION_BASE	DEBUG_INFO_SECTION "_base"
+#define TEXT_SECTION_BASE	TEXT_SECTION "_base"
+
 
 /* Definitions of defaults for formats and names of various special
    (artificial) labels which may be generated within this file (when the -g
@@ -5423,7 +5434,7 @@ output_compilation_unit_header ()
     fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (abbrev_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
 	     ASM_COMMENT_START);
@@ -5496,7 +5507,7 @@ output_pubnames ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (debug_info_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5577,7 +5588,7 @@ output_aranges ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (debug_info_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5603,13 +5614,13 @@ output_aranges ()
 	     ASM_COMMENT_START, 2 * PTR_SIZE);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (text_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
-			       stripattributes (TEXT_SECTION));
+			       stripattributes (text_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
 
@@ -5794,7 +5805,7 @@ output_line_info ()
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (text_section_base->s));
   fputc ('\n', asm_out_file);
 
   /* Generate the line number to PC correspondence table, encoded as
@@ -9851,6 +9862,29 @@ dwarf2out_init (asm_out_file, main_input
   gen_compile_unit_die (main_input_filename);
 
   ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
+
+  abbrev_section_base = dyn_string_new (32);
+  text_section_base = dyn_string_new (32);
+  debug_info_section_base = dyn_string_new (32);
+  debug_line_section_base = dyn_string_new (32);
+
+  dyn_string_append(abbrev_section_base, ABBREV_SECTION);
+  dyn_string_append(abbrev_section_base, "_base");
+  dyn_string_append(text_section_base, TEXT_SECTION);
+  dyn_string_append(text_section_base, "_base");
+  dyn_string_append(debug_info_section_base, DEBUG_INFO_SECTION);
+  dyn_string_append(debug_info_section_base, "_base");
+  dyn_string_append(debug_line_section_base, DEBUG_LINE_SECTION);
+  dyn_string_append(debug_line_section_base, "_base");
+
+  ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, abbrev_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, TEXT_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, text_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_INFO_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_info_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_base->s);
 }
 
 /* Output stuff that dwarf requires at the end of every file,
@@ -9911,7 +9945,7 @@ dwarf2out_finish ()
   if (line_info_table_in_use > 1 || separate_line_info_table_in_use)
     {
       fputc ('\n', asm_out_file);
-      ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+      ASM_OUTPUT_SECTION (asm_out_file, debug_line_section_base->s);
       output_line_info ();
 
       /* We can only use the low/high_pc attributes if all of the code
@@ -9919,11 +9953,11 @@ dwarf2out_finish ()
       if (separate_line_info_table_in_use == 0)
 	{
 	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
-			 stripattributes (TEXT_SECTION));
+			 stripattributes (text_section_base->s));
 	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
 	}
 
-      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION);
+      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, debug_line_section_base->s);
     }
 
   /* Output the abbreviation table.  */

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

I don't think we need anything so complex.  I'd look at the code in
dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
labels rfg defined there...

Jason

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

After actually reading the comments in dwarfout.c, the thought occurs that
using ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL would be better, but you can
still get away with using the same label name regardless of the definition
of TEXT_SECTION et al.

As a historical note, dwarf2out used to do things the same way that
dwarfout does, but I changed it...

Jason

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> I don't think we need anything so complex.  I'd look at the code in
> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
> labels rfg defined there...

I do find that less sickening.

Does it bother you that iwth this scheme, your original request of
"slightly modifying the section name" isn't an automatic thing?   My
way would keep the symbol name tracking the section name if it were
overridden in a target file.

Thanx,
RJL

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 >> I don't think we need anything so complex.  I'd look at the code in
 >> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
 >> labels rfg defined there...

 > I do find that less sickening.

 > Does it bother you that iwth this scheme, your original request of
 > "slightly modifying the section name" isn't an automatic thing?

Not at all.  That was just an idea.

Jason

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> I don't think we need anything so complex.  I'd look at the code in
> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
> labels rfg defined there...

Yes, that is indeed more appealing.  With this installed, an empty C
program will assemble and link on SVR5.

If you're OK with this approach, I'll send in a ChangeLog and describe
what I did and why as comments in the code.

If the comment in dwarfout.c before TEXT_BEGIN_LABEL is to be believed,
we might have to make these labels '.Lblah'.  My assembler doesn't make
them global with just the leading dot.   Your call.

Thanx for the help.
RJL


Index: dwarf2out.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/dwarf2out.c,v
retrieving revision 1.85
diff -c -5 -p -r1.85 dwarf2out.c
*** dwarf2out.c	1999/02/24 17:48:42	1.85
--- dwarf2out.c	1999/02/26 06:10:59
*************** static unsigned lookup_filename		PROTO((
*** 2622,2632 ****
--- 2622,2648 ----
  #endif
  #ifndef BSS_SECTION
  #define BSS_SECTION		".bss"
  #endif
  
+ /* Labels we insert at beginning sections we can reference instead of
+    the section names themselves. */
  
+ #ifndef TEXT_SECTION_LABEL
+ #define TEXT_SECTION_LABEL	".text_label"
+ #endif
+ #ifndef  DEBUG_LINE_SECTION_LABEL
+ #define DEBUG_LINE_SECTION_LABEL ".debug_line_label"
+ #endif
+ #ifndef  DEBUG_INFO_SECTION_LABEL
+ #define DEBUG_INFO_SECTION_LABEL ".debug_info_label"
+ #endif
+ #ifndef  ABBREV_SECTION_LABEL
+ #define ABBREV_SECTION_LABEL ".debug_abbrev_label"
+ #endif
+ 
+ 
  /* Definitions of defaults for formats and names of various special
     (artificial) labels which may be generated within this file (when the -g
     options is used and DWARF_DEBUGGING_INFO is in effect.
     If necessary, these may be overridden from within the tm.h file, but
     typically, overriding these defaults is unnecessary.  */
*************** output_compilation_unit_header ()
*** 5421,5431 ****
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5437,5447 ----
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_pubnames ()
*** 5494,5504 ****
  
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5510,5520 ----
  
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_aranges ()
*** 5575,5585 ****
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5591,5601 ----
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_aranges ()
*** 5601,5617 ****
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Pad to %d byte boundary",
  	     ASM_COMMENT_START, 2 * PTR_SIZE);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
! 			       stripattributes (TEXT_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    for (i = 0; i < arange_table_in_use; ++i)
--- 5617,5633 ----
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Pad to %d byte boundary",
  	     ASM_COMMENT_START, 2 * PTR_SIZE);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
! 			       stripattributes (TEXT_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    for (i = 0; i < arange_table_in_use; ++i)
*************** output_line_info ()
*** 5792,5809 ****
    fputc ('\n', asm_out_file);
    output_uleb128 (1 + PTR_SIZE);
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
    fputc ('\n', asm_out_file);
  
    /* Generate the line number to PC correspondence table, encoded as
       a series of state machine operations.  */
    current_file = 1;
    current_line = 1;
!   strcpy (prev_line_label, stripattributes (TEXT_SECTION));
    for (lt_index = 1; lt_index < line_info_table_in_use; ++lt_index)
      {
        register dw_line_info_ref line_info;
  
        /* Emit debug info for the address of the current line, choosing
--- 5808,5825 ----
    fputc ('\n', asm_out_file);
    output_uleb128 (1 + PTR_SIZE);
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION_LABEL));
    fputc ('\n', asm_out_file);
  
    /* Generate the line number to PC correspondence table, encoded as
       a series of state machine operations.  */
    current_file = 1;
    current_line = 1;
!   strcpy (prev_line_label, stripattributes (TEXT_SECTION_LABEL));
    for (lt_index = 1; lt_index < line_info_table_in_use; ++lt_index)
      {
        register dw_line_info_ref line_info;
  
        /* Emit debug info for the address of the current line, choosing
*************** dwarf2out_init (asm_out_file, main_input
*** 9849,9858 ****
--- 9865,9883 ----
       taken as being relative to the directory from which the compiler was
       invoked when the given (base) source file was compiled.  */
    gen_compile_unit_die (main_input_filename);
  
    ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
+ 
+   ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, ABBREV_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, TEXT_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, TEXT_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, DEBUG_INFO_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, DEBUG_INFO_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, DEBUG_LINE_SECTION_LABEL);
  }
  
  /* Output stuff that dwarf requires at the end of every file,
     and generate the DWARF-2 debugging info.  */
  
*************** dwarf2out_finish ()
*** 9917,9931 ****
        /* We can only use the low/high_pc attributes if all of the code
  	 was in .text.  */
        if (separate_line_info_table_in_use == 0)
  	{
  	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
! 			 stripattributes (TEXT_SECTION));
  	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
  	}
  
!       add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION);
      }
  
    /* Output the abbreviation table.  */
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
--- 9942,9956 ----
        /* We can only use the low/high_pc attributes if all of the code
  	 was in .text.  */
        if (separate_line_info_table_in_use == 0)
  	{
  	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
! 			 stripattributes (TEXT_SECTION_LABEL));
  	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
  	}
  
!       add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION_LABEL);
      }
  
    /* Output the abbreviation table.  */
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 > If the comment in dwarfout.c before TEXT_BEGIN_LABEL is to be believed,
 > we might have to make these labels '.Lblah'.  My assembler doesn't make
 > them global with just the leading dot.   Your call.

Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
handle such matters, like we do for text_end_label (and as the comment in
dwarfout.c suggests).  That's a bit more complicated than this approach,
but more correct.

Jason

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
> handle such matters, like we do for text_end_label (and as the comment in
> dwarfout.c suggests).  That's a bit more complicated than this approach,
> but more correct.


This isn't quite right, but I'm calling it a night.   

From the hip, my guess is that add_AT_section_offset() is calling
stripattributes() on that third argument which is no longer appropriate.

The bogus code looks like:

        .ascii "/tmp/x.c\0"     / DW_AT_name
        .ascii "/home3/negcs/gcc\0"     / DW_AT_comp_dir
        .ascii "GNU C egcs-2.93.09 19990225 (gcc2 ss-980929 experimental)\0"
/ DW_AT_producer
        .byte   0x1     / DW_AT_language
        .4byte  .Ltext_label0   / DW_AT_low_pc
        .4byte  .Letext0        / DW_AT_high_pc
->        .4byte  *.Ldebug_line_label0    / DW_AT_stmt_list
        .byte   0x2     / ULEB128 0x2 (DIE (0x6d) DW_TAG_subprogram)
        .byte   0x1     / DW_AT_external

Remove the '*' from that line, and it compiles and links again.



Index: dwarf2out.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/dwarf2out.c,v
retrieving revision 1.85
diff -u -p -r1.85 dwarf2out.c
--- dwarf2out.c	1999/02/24 17:48:42	1.85
+++ dwarf2out.c	1999/02/26 07:21:27
@@ -2624,7 +2624,23 @@ static unsigned lookup_filename		PROTO((
 #define BSS_SECTION		".bss"
 #endif
 
+/* Labels we insert at beginning sections we can reference instead of
+   the section names themselves. */
 
+#ifndef TEXT_SECTION_LABEL
+#define TEXT_SECTION_LABEL	"Ltext_label"
+#endif
+#ifndef  DEBUG_LINE_SECTION_LABEL
+#define DEBUG_LINE_SECTION_LABEL "Ldebug_line_label"
+#endif
+#ifndef  DEBUG_INFO_SECTION_LABEL
+#define DEBUG_INFO_SECTION_LABEL "Ldebug_info_label"
+#endif
+#ifndef  ABBREV_SECTION_LABEL
+#define ABBREV_SECTION_LABEL "Ldebug_abbrev_label"
+#endif
+
+
 /* Definitions of defaults for formats and names of various special
    (artificial) labels which may be generated within this file (when the -g
    options is used and DWARF_DEBUGGING_INFO is in effect.
@@ -2632,6 +2648,10 @@ static unsigned lookup_filename		PROTO((
    typically, overriding these defaults is unnecessary.  */
 
 static char text_end_label[MAX_ARTIFICIAL_LABEL_BYTES];
+static char text_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
+static char abbrev_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
+static char debug_info_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
+static char debug_line_section_label[MAX_ARTIFICIAL_LABEL_BYTES];
 
 #ifndef TEXT_END_LABEL
 #define TEXT_END_LABEL		"Letext"
@@ -5423,7 +5443,7 @@ output_compilation_unit_header ()
     fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, abbrev_section_label);
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
 	     ASM_COMMENT_START);
@@ -5496,7 +5516,7 @@ output_pubnames ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, debug_info_section_label);
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5577,7 +5597,7 @@ output_aranges ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, debug_info_section_label);
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5603,13 +5623,13 @@ output_aranges ()
 	     ASM_COMMENT_START, 2 * PTR_SIZE);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, text_section_label);
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
-			       stripattributes (TEXT_SECTION));
+			       text_section_label);
   if (flag_debug_asm)
     fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
 
@@ -5794,14 +5814,14 @@ output_line_info ()
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, text_section_label);
   fputc ('\n', asm_out_file);
 
   /* Generate the line number to PC correspondence table, encoded as
      a series of state machine operations.  */
   current_file = 1;
   current_line = 1;
-  strcpy (prev_line_label, stripattributes (TEXT_SECTION));
+  strcpy (prev_line_label, text_section_label);
   for (lt_index = 1; lt_index < line_info_table_in_use; ++lt_index)
     {
       register dw_line_info_ref line_info;
@@ -9851,6 +9871,21 @@ dwarf2out_init (asm_out_file, main_input
   gen_compile_unit_die (main_input_filename);
 
   ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
+  ASM_GENERATE_INTERNAL_LABEL (abbrev_section_label, ABBREV_SECTION_LABEL, 0);
+  ASM_GENERATE_INTERNAL_LABEL (text_section_label, TEXT_SECTION_LABEL, 0);
+  ASM_GENERATE_INTERNAL_LABEL (debug_info_section_label, 
+			       DEBUG_INFO_SECTION_LABEL, 0);
+  ASM_GENERATE_INTERNAL_LABEL (debug_line_section_label, 
+			       DEBUG_LINE_SECTION_LABEL, 0);
+
+  ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, abbrev_section_label);
+  ASM_OUTPUT_SECTION (asm_out_file, TEXT_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, text_section_label);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_INFO_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_info_section_label);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_label);
 }
 
 /* Output stuff that dwarf requires at the end of every file,
@@ -9918,12 +9953,11 @@ dwarf2out_finish ()
 	 was in .text.  */
       if (separate_line_info_table_in_use == 0)
 	{
-	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
-			 stripattributes (TEXT_SECTION));
+	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc, text_section_label);
 	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
 	}
 
-      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION);
+      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, debug_line_section_label);
     }
 
   /* Output the abbreviation table.  */

Re: dwarf2 debug dependent upon GAS?

[Jeffrey A Law]

  In message < 19990226012522.D17655@rjlhome.sco.com >you write:
  > > Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
  > > handle such matters, like we do for text_end_label (and as the comment in
  > > dwarfout.c suggests).  That's a bit more complicated than this approach,
  > > but more correct.
  > 
  > 
  > This isn't quite right, but I'm calling it a night.   
  > 
  > >From the hip, my guess is that add_AT_section_offset() is calling
  > stripattributes() on that third argument which is no longer appropriate.
  > 
  > The bogus code looks like:
  > 
  >         .ascii "/tmp/x.c\0"     / DW_AT_name
  >         .ascii "/home3/negcs/gcc\0"     / DW_AT_comp_dir
  >         .ascii "GNU C egcs-2.93.09 19990225 (gcc2 ss-980929 experimental)\0
  > "
  > / DW_AT_producer
  >         .byte   0x1     / DW_AT_language
  >         .4byte  .Ltext_label0   / DW_AT_low_pc
  >         .4byte  .Letext0        / DW_AT_high_pc
  > ->        .4byte  *.Ldebug_line_label0    / DW_AT_stmt_list
  >         .byte   0x2     / ULEB128 0x2 (DIE (0x6d) DW_TAG_subprogram)
  >         .byte   0x1     / DW_AT_external
  > 
  > Remove the '*' from that line, and it compiles and links again.
This looks a lot like something I had to fight not long ago.

Basically all this code is bypassing the logic to strip out unwanted stuff
from the symbol.

In my case it was easier to just put the label into an operand and use the
%<opnum> syntax of output_asm_insn to do what I needed to do.  I don't know
if that kind of solution will work for what you are doing though.

[ See ashrdi3_non_const_int in the x86 port ].


jeff

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

Hi, Jim.

Thanx for the reply.

> It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
> assemblers that I know about.

The native compiler and debugger on SVR5 munch dwarf2 by default.  I
don't know how aware of dwarf the assembler really is.

> The latter, sort of.  The dwarf2 standard says that some fields are offsets
> relative to the address of the final linked section.  This means that we can't
> compute these offsets until link time.

Is there some sort of tool that a human can use to help read these
tables?  I can examine the output of 'main(){}' compiled with a native
compiler using -g, but the tables are complex enough that I can't
readily parse them in my head to see how this issue is sidestepped on
the native tools.


I've asked the SCO tool dudes to offer hints.

Thanx,
RJL

Re: dwarf2 debug dependent upon GAS?

[Jim Wilson]

In article <19990221144644.M8783.cygnus.egcs@rjlhome.sco.com> you write:
>I've had it on my list to examine Dwarf2 debugging for System V.  I'm
>finding that it seems to depend upon a curiosity of the GNU assembler.
>Is this accurate?

It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
assemblers that I know about.

There are clear advantages to having a dwarf2 aware assembler when emitting
dwarf2 debug info.  There is only this one curiousity we need for correctness,
but there are a number of cases where special assembler support would give us
more compact debug info.  We currently don't take advantage of any GNU as
features for this yet, but I expect we will eventually.  This will mean that
we'll have smaller debug info if we use GNU as.

>I'm seeing EGCS (current trunk) generate refences to symbols that don't
>exist.  There are SECTIONS of that name, but no symbols.  Apparently
>GAS treat them interchangably.  Is it the intent for these to reference
>the beginning of the section in this file (i.e. local labels) or the
>beginning of that section once linked? (without making them global, I
>don't know how I would synthesize that.)

The latter, sort of.  The dwarf2 standard says that some fields are offsets
relative to the address of the final linked section.  This means that we can't
compute these offsets until link time.

You can get this effect by using a section name as a symbol name in GNU as
and SGI irix6 as.

If you don't have relocations and assembler syntax for this, then it will
be hard to synthesize it.  It might be possible to get the same effect
by creating a file that always gets linked first, and which contains special
labels to mark the start of each section, and then use label subtraction to
get an offset.  There are cases where this won't work, but I don't recall the
details.  I've discussed this before with other people and never found a
satisfactory solution.

There is some language in the MIPS processor supplement to the SVR4 ABI 
that seems to document this.  In the section Relocation, it defines a symbol
(S) relocation as
	Represents the value of the symbol whose index resides in the
	relocation entry, unless the symbol is STB_LOCAL and is of type
	STT_SECTION, in which case S represents the original sh_addr minus
	the final sh_addr.
and that gives the result that we want.  I haven't found similar language in
any other SVR4 ABI.  I don't know how this got into the MIPS SVR4 ABI.  This
is a 1990 copyright document, but dwarf2 didn't exist until several years
later, so it seems unlikely that it was added specifically for dwarf2.

If we can't get the exact result that the standard asks for, then perhaps
we can create a dwarf2-variant for dwarf2-unaware assemblers.  For instance,
substituting in an absolute address where the standard wants a section-relative
offset might make some of these problems go away.  This would require some
support in gdb for the dwarf2-variant though.

Jim

Re: dwarf2 debug dependent upon GAS?

[Daniel Berlin]

> Brian Ford wrote:
>
> > On Mon, 22 Feb 1999, Robert Lipe wrote:
> >
> > > Is there some sort of tool that a human can use to help read [dwarf]
> > > tables?
> >
> > I'm not exactly sure what you are asking for, but would dwarfdump do
> > the trick?
>
> From the name, it sounds interesting.  Does dwarfdump exist outside of
> the SGI/MIPS tool kit?
>
> If it doesn't, it doesn't do me much good.
>
>

I have a dwarf2 dumper (more of a reader, it can dump it in a nicely
readable format as a side effect) written in python, which means it should
be portable just about anywhere.
It only works on ELF executables , but if you can give it the offsets of the
various debug sections, and such, it'll happily read them and process them.
The only thing it doesn't do right now is location expressions, because i
just haven't gotten around to it (it's rather easy, you just need to
describe the structure to it).
It's part of a debugger i wrote for BeOS.  I got tired of writing the dwarf2
reading/processing code in C++, it was just much easier in python, and
easier to maintain.  In addition to dumping the info, it also builds and
keeps track of a hashtable and a proper "general" tree of each compilation
unit, keyed on the offsets.
I also have a c module for the structure unpacker i wrote that it uses,
which makes it take 3 seconds to read and process large amount of debug info
(3 meg in this case), as opposed to 20 for the straight python code ( You
shouldn't run into alignment issues on the C code, as it was written with
avoiding them in mind. I could be wrong, however.)

Lemme know if you want it (or anyone else for that matter, just put "python
dwarf2 code" in the subject so it goes into the right folder)
Dan

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

I don't think we need anything so complex.  I'd look at the code in
dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
labels rfg defined there...

Jason

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 > If the comment in dwarfout.c before TEXT_BEGIN_LABEL is to be believed,
 > we might have to make these labels '.Lblah'.  My assembler doesn't make
 > them global with just the leading dot.   Your call.

Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
handle such matters, like we do for text_end_label (and as the comment in
dwarfout.c suggests).  That's a bit more complicated than this approach,
but more correct.

Jason

Re: dwarf2 debug dependent upon GAS?

[Brian Ford]

On Mon, 22 Feb 1999, Robert Lipe wrote:

> Hi, Jim.
> 
> Thanx for the reply.
> 
> > It works with GNU as and SGI Irix6 as.  Those are the only dwarf2 aware
> > assemblers that I know about.
> 
> The native compiler and debugger on SVR5 munch dwarf2 by default.  I
> don't know how aware of dwarf the assembler really is.
> 
> > The latter, sort of.  The dwarf2 standard says that some fields are offsets
> > relative to the address of the final linked section.  This means that we can't
> > compute these offsets until link time.
> 
> Is there some sort of tool that a human can use to help read these
> tables?  I can examine the output of 'main(){}' compiled with a native
> compiler using -g, but the tables are complex enough that I can't
> readily parse them in my head to see how this issue is sidestepped on
> the native tools.
> 
I'm not exactly sure what you are asking for, but would dwarfdump do the
trick?

> 
> I've asked the SCO tool dudes to offer hints.
> 
> Thanx,
> RJL
> 

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> I don't think we need anything so complex.  I'd look at the code in
> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
> labels rfg defined there...

Yes, that is indeed more appealing.  With this installed, an empty C
program will assemble and link on SVR5.

If you're OK with this approach, I'll send in a ChangeLog and describe
what I did and why as comments in the code.

If the comment in dwarfout.c before TEXT_BEGIN_LABEL is to be believed,
we might have to make these labels '.Lblah'.  My assembler doesn't make
them global with just the leading dot.   Your call.

Thanx for the help.
RJL


Index: dwarf2out.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/dwarf2out.c,v
retrieving revision 1.85
diff -c -5 -p -r1.85 dwarf2out.c
*** dwarf2out.c	1999/02/24 17:48:42	1.85
--- dwarf2out.c	1999/02/26 06:10:59
*************** static unsigned lookup_filename		PROTO((
*** 2622,2632 ****
--- 2622,2648 ----
  #endif
  #ifndef BSS_SECTION
  #define BSS_SECTION		".bss"
  #endif
  
+ /* Labels we insert at beginning sections we can reference instead of
+    the section names themselves. */
  
+ #ifndef TEXT_SECTION_LABEL
+ #define TEXT_SECTION_LABEL	".text_label"
+ #endif
+ #ifndef  DEBUG_LINE_SECTION_LABEL
+ #define DEBUG_LINE_SECTION_LABEL ".debug_line_label"
+ #endif
+ #ifndef  DEBUG_INFO_SECTION_LABEL
+ #define DEBUG_INFO_SECTION_LABEL ".debug_info_label"
+ #endif
+ #ifndef  ABBREV_SECTION_LABEL
+ #define ABBREV_SECTION_LABEL ".debug_abbrev_label"
+ #endif
+ 
+ 
  /* Definitions of defaults for formats and names of various special
     (artificial) labels which may be generated within this file (when the -g
     options is used and DWARF_DEBUGGING_INFO is in effect.
     If necessary, these may be overridden from within the tm.h file, but
     typically, overriding these defaults is unnecessary.  */
*************** output_compilation_unit_header ()
*** 5421,5431 ****
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5437,5447 ----
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_pubnames ()
*** 5494,5504 ****
  
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5510,5520 ----
  
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_aranges ()
*** 5575,5585 ****
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
--- 5591,5601 ----
    ASM_OUTPUT_DWARF_DATA2 (asm_out_file, DWARF_VERSION);
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
  	     ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
*************** output_aranges ()
*** 5601,5617 ****
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Pad to %d byte boundary",
  	     ASM_COMMENT_START, 2 * PTR_SIZE);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
! 			       stripattributes (TEXT_SECTION));
    if (flag_debug_asm)
      fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    for (i = 0; i < arange_table_in_use; ++i)
--- 5617,5633 ----
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Pad to %d byte boundary",
  	     ASM_COMMENT_START, 2 * PTR_SIZE);
  
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
! 			       stripattributes (TEXT_SECTION_LABEL));
    if (flag_debug_asm)
      fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
  
    fputc ('\n', asm_out_file);
    for (i = 0; i < arange_table_in_use; ++i)
*************** output_line_info ()
*** 5792,5809 ****
    fputc ('\n', asm_out_file);
    output_uleb128 (1 + PTR_SIZE);
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
    fputc ('\n', asm_out_file);
  
    /* Generate the line number to PC correspondence table, encoded as
       a series of state machine operations.  */
    current_file = 1;
    current_line = 1;
!   strcpy (prev_line_label, stripattributes (TEXT_SECTION));
    for (lt_index = 1; lt_index < line_info_table_in_use; ++lt_index)
      {
        register dw_line_info_ref line_info;
  
        /* Emit debug info for the address of the current line, choosing
--- 5808,5825 ----
    fputc ('\n', asm_out_file);
    output_uleb128 (1 + PTR_SIZE);
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
    fputc ('\n', asm_out_file);
!   ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION_LABEL));
    fputc ('\n', asm_out_file);
  
    /* Generate the line number to PC correspondence table, encoded as
       a series of state machine operations.  */
    current_file = 1;
    current_line = 1;
!   strcpy (prev_line_label, stripattributes (TEXT_SECTION_LABEL));
    for (lt_index = 1; lt_index < line_info_table_in_use; ++lt_index)
      {
        register dw_line_info_ref line_info;
  
        /* Emit debug info for the address of the current line, choosing
*************** dwarf2out_init (asm_out_file, main_input
*** 9849,9858 ****
--- 9865,9883 ----
       taken as being relative to the directory from which the compiler was
       invoked when the given (base) source file was compiled.  */
    gen_compile_unit_die (main_input_filename);
  
    ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
+ 
+   ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, ABBREV_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, TEXT_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, TEXT_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, DEBUG_INFO_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, DEBUG_INFO_SECTION_LABEL);
+   ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+   ASM_OUTPUT_LABEL (asm_out_file, DEBUG_LINE_SECTION_LABEL);
  }
  
  /* Output stuff that dwarf requires at the end of every file,
     and generate the DWARF-2 debugging info.  */
  
*************** dwarf2out_finish ()
*** 9917,9931 ****
        /* We can only use the low/high_pc attributes if all of the code
  	 was in .text.  */
        if (separate_line_info_table_in_use == 0)
  	{
  	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
! 			 stripattributes (TEXT_SECTION));
  	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
  	}
  
!       add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION);
      }
  
    /* Output the abbreviation table.  */
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
--- 9942,9956 ----
        /* We can only use the low/high_pc attributes if all of the code
  	 was in .text.  */
        if (separate_line_info_table_in_use == 0)
  	{
  	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
! 			 stripattributes (TEXT_SECTION_LABEL));
  	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
  	}
  
!       add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION_LABEL);
      }
  
    /* Output the abbreviation table.  */
    fputc ('\n', asm_out_file);
    ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
> handle such matters, like we do for text_end_label (and as the comment in
> dwarfout.c suggests).  That's a bit more complicated than this approach,
> but more correct.


This isn't quite right, but I'm calling it a night.   

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

Brian Ford wrote:

> On Mon, 22 Feb 1999, Robert Lipe wrote:
>
> > Is there some sort of tool that a human can use to help read [dwarf]
> > tables?
>
> I'm not exactly sure what you are asking for, but would dwarfdump do
> the trick?

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

> I don't think we need anything so complex.  I'd look at the code in
> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
> labels rfg defined there...

I do find that less sickening.

Does it bother you that iwth this scheme, your original request of
"slightly modifying the section name" isn't an automatic thing?   My
way would keep the symbol name tracking the section name if it were
overridden in a target file.

Thanx,
RJL

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 >> I don't think we need anything so complex.  I'd look at the code in
 >> dwarfout.c; TEXT_BEGIN_LABEL et al.  Of course, you don't need all of the
 >> labels rfg defined there...

 > I do find that less sickening.

 > Does it bother you that iwth this scheme, your original request of
 > "slightly modifying the section name" isn't an automatic thing?

Not at all.  That was just an idea.

Jason

Re: dwarf2 debug dependent upon GAS?

[Robert Lipe]

>  > What would be the best way to handle this?  Something like letting
>  > ASM_OUTPUT_SECTION_NAME watch for the first time any of the 'debug_'
>  > sections are emitted and then letting it emit a symbol of the same name?
> 
> Nah, just spit out the useful ones in dwarf2out_init.
> 
>  > The random symbol could be the section name, right?
> 
> I'd suggest a variant on the section name so we can use that solution for
> all targets.

This turned ugly.  In the process it became a spokesperson for use of
ANSI string pasting, but I know that's a no-no for us.

It does allow an empty C file to assemble and link on SVR5 when using
-gdwarf-2.  Still, it "feels" wrong.  Before I continue down this path,
can you please tell me if I should perhaps go a different way?

Thanx,
RJL




Index: dwarf2out.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/dwarf2out.c,v
retrieving revision 1.85
diff -u -p -r1.85 dwarf2out.c
--- dwarf2out.c	1999/02/24 17:48:42	1.85
+++ dwarf2out.c	1999/02/26 04:50:54
@@ -2613,6 +2613,7 @@ static unsigned lookup_filename		PROTO((
 #define STR_SECTION		".debug_str"
 #endif
 
+
 /* Standard ELF section names for compiled code and data.  */
 #ifndef TEXT_SECTION
 #define TEXT_SECTION		".text"
@@ -2624,6 +2625,16 @@ static unsigned lookup_filename		PROTO((
 #define BSS_SECTION		".bss"
 #endif
 
+dyn_string_t abbrev_section_base;
+dyn_string_t debug_line_section_base;
+dyn_string_t debug_info_section_base;
+dyn_string_t text_section_base;
+
+#define ABBREV_SECTION_BASE	ABBREV_SECTION "_base"
+#define DEBUG_LINE_SECTION_BASE	DEBUG_LINE_SECTION "_base"
+#define DEBUG_INFO_SECTION_BASE	DEBUG_INFO_SECTION "_base"
+#define TEXT_SECTION_BASE	TEXT_SECTION "_base"
+
 
 /* Definitions of defaults for formats and names of various special
    (artificial) labels which may be generated within this file (when the -g
@@ -5423,7 +5434,7 @@ output_compilation_unit_header ()
     fprintf (asm_out_file, "\t%s DWARF version number", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (ABBREV_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (abbrev_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset Into Abbrev. Section",
 	     ASM_COMMENT_START);
@@ -5496,7 +5507,7 @@ output_pubnames ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (debug_info_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5577,7 +5588,7 @@ output_aranges ()
     fprintf (asm_out_file, "\t%s DWARF Version", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (DEBUG_INFO_SECTION));
+  ASM_OUTPUT_DWARF_OFFSET (asm_out_file, stripattributes (debug_info_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Offset of Compilation Unit Info.",
 	     ASM_COMMENT_START);
@@ -5603,13 +5614,13 @@ output_aranges ()
 	     ASM_COMMENT_START, 2 * PTR_SIZE);
 
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (text_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "\t%s Address", ASM_COMMENT_START);
 
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_ADDR_DELTA (asm_out_file, text_end_label,
-			       stripattributes (TEXT_SECTION));
+			       stripattributes (text_section_base->s));
   if (flag_debug_asm)
     fprintf (asm_out_file, "%s Length", ASM_COMMENT_START);
 
@@ -5794,7 +5805,7 @@ output_line_info ()
   fputc ('\n', asm_out_file);
   ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_LNE_set_address);
   fputc ('\n', asm_out_file);
-  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (TEXT_SECTION));
+  ASM_OUTPUT_DWARF_ADDR (asm_out_file, stripattributes (text_section_base->s));
   fputc ('\n', asm_out_file);
 
   /* Generate the line number to PC correspondence table, encoded as
@@ -9851,6 +9862,29 @@ dwarf2out_init (asm_out_file, main_input
   gen_compile_unit_die (main_input_filename);
 
   ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
+
+  abbrev_section_base = dyn_string_new (32);
+  text_section_base = dyn_string_new (32);
+  debug_info_section_base = dyn_string_new (32);
+  debug_line_section_base = dyn_string_new (32);
+
+  dyn_string_append(abbrev_section_base, ABBREV_SECTION);
+  dyn_string_append(abbrev_section_base, "_base");
+  dyn_string_append(text_section_base, TEXT_SECTION);
+  dyn_string_append(text_section_base, "_base");
+  dyn_string_append(debug_info_section_base, DEBUG_INFO_SECTION);
+  dyn_string_append(debug_info_section_base, "_base");
+  dyn_string_append(debug_line_section_base, DEBUG_LINE_SECTION);
+  dyn_string_append(debug_line_section_base, "_base");
+
+  ASM_OUTPUT_SECTION (asm_out_file, ABBREV_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, abbrev_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, TEXT_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, text_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_INFO_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_info_section_base->s);
+  ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_base->s);
 }
 
 /* Output stuff that dwarf requires at the end of every file,
@@ -9911,7 +9945,7 @@ dwarf2out_finish ()
   if (line_info_table_in_use > 1 || separate_line_info_table_in_use)
     {
       fputc ('\n', asm_out_file);
-      ASM_OUTPUT_SECTION (asm_out_file, DEBUG_LINE_SECTION);
+      ASM_OUTPUT_SECTION (asm_out_file, debug_line_section_base->s);
       output_line_info ();
 
       /* We can only use the low/high_pc attributes if all of the code
@@ -9919,11 +9953,11 @@ dwarf2out_finish ()
       if (separate_line_info_table_in_use == 0)
 	{
 	  add_AT_lbl_id (comp_unit_die, DW_AT_low_pc,
-			 stripattributes (TEXT_SECTION));
+			 stripattributes (text_section_base->s));
 	  add_AT_lbl_id (comp_unit_die, DW_AT_high_pc, text_end_label);
 	}
 
-      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION);
+      add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, debug_line_section_base->s);
     }
 
   /* Output the abbreviation table.  */

Re: dwarf2 debug dependent upon GAS?

[Jeffrey A Law]

  In message < 19990226012522.D17655@rjlhome.sco.com >you write:
  > > Actually, I think we should use ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL to
  > > handle such matters, like we do for text_end_label (and as the comment in
  > > dwarfout.c suggests).  That's a bit more complicated than this approach,
  > > but more correct.
  > 
  > 
  > This isn't quite right, but I'm calling it a night.   
  > 
  > >From the hip, my guess is that add_AT_section_offset() is calling
  > stripattributes() on that third argument which is no longer appropriate.
  > 
  > The bogus code looks like:
  > 
  >         .ascii "/tmp/x.c\0"     / DW_AT_name
  >         .ascii "/home3/negcs/gcc\0"     / DW_AT_comp_dir
  >         .ascii "GNU C egcs-2.93.09 19990225 (gcc2 ss-980929 experimental)\0
  > "
  > / DW_AT_producer
  >         .byte   0x1     / DW_AT_language
  >         .4byte  .Ltext_label0   / DW_AT_low_pc
  >         .4byte  .Letext0        / DW_AT_high_pc
  > ->        .4byte  *.Ldebug_line_label0    / DW_AT_stmt_list
  >         .byte   0x2     / ULEB128 0x2 (DIE (0x6d) DW_TAG_subprogram)
  >         .byte   0x1     / DW_AT_external
  > 
  > Remove the '*' from that line, and it compiles and links again.
This looks a lot like something I had to fight not long ago.

Basically all this code is bypassing the logic to strip out unwanted stuff
from the symbol.

In my case it was easier to just put the label into an operand and use the
%<opnum> syntax of output_asm_insn to do what I needed to do.  I don't know
if that kind of solution will work for what you are doing though.

[ See ashrdi3_non_const_int in the x86 port ].


jeff

Re: dwarf2 debug dependent upon GAS?

[Jim Wilson]

irix6 has a program called dwarfdump which is very nice.  I don't know where
else it is available.  There has been some work on adding dwarf2 dumping to
the binutils readelf program.  You'd have to get a recent binutils snapshot
to try it though.  Using gcc -dA -S gives you readable commented assembler
files which might help.

Jim

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Robert Lipe <robertl@sco.com> writes:

 > Our staff that was around at the time of the original SVR4 on 3B2
 > (remember, SCO bought The Organization Formerly Known As USL) says their
 > assembler/linker didn't do this.

OK.

 > What would be the best way to handle this?  Something like letting
 > ASM_OUTPUT_SECTION_NAME watch for the first time any of the 'debug_'
 > sections are emitted and then letting it emit a symbol of the same name?

Nah, just spit out the useful ones in dwarf2out_init.

 > The random symbol could be the section name, right?

I'd suggest a variant on the section name so we can use that solution for
all targets.

Jason

Re: dwarf2 debug dependent upon GAS?

[Brian Ford]

On Tue, 23 Feb 1999, Robert Lipe wrote:

> Brian Ford wrote:
> 
> > On Mon, 22 Feb 1999, Robert Lipe wrote:
> >
> > > Is there some sort of tool that a human can use to help read [dwarf]
> > > tables?
> >
> > I'm not exactly sure what you are asking for, but would dwarfdump do
> > the trick?
> 
> >From the name, it sounds interesting.  Does dwarfdump exist outside of
> the SGI/MIPS tool kit?
> 
> If it doesn't, it doesn't do me much good.
> 
> 
Sorry, I don't know.  Probably not, though.

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

>>>>> Jim Wilson <wilson@cygnus.com> writes:

 >> I'm seeing EGCS (current trunk) generate refences to symbols that don't
 >> exist.  There are SECTIONS of that name, but no symbols.  Apparently
 >> GAS treat them interchangably.  Is it the intent for these to reference
 >> the beginning of the section in this file (i.e. local labels) or the
 >> beginning of that section once linked? (without making them global, I
 >> don't know how I would synthesize that.)

 > The latter, sort of.  The dwarf2 standard says that some fields are
 > offsets relative to the address of the final linked section.  This means
 > that we can't compute these offsets until link time.

Actually, it's a lot simpler than that.  The references are not to the
beginning of the section in the executable, but to the offset from there to
the beginning of the info for the particular translation unit.  Since the
beginning of the section is at 0, this simplifies to the address of the
beginning of the section in question for the current translation unit.  In
GNU as, SGI as and Sun as, referring to a section name as a symbol gives us
that.  If SCO doesn't support this feature (which I assumed was standard
SVR4), it would be simple enough to emit some random symbol at the
beginning of the assembly output and refer to that instead.

Jason

Re: dwarf2 debug dependent upon GAS?

[Jason Merrill]

After actually reading the comments in dwarfout.c, the thought occurs that
using ASM_{GENERATE,OUTPUT}_INTERNAL_LABEL would be better, but you can
still get away with using the same label name regardless of the definition
of TEXT_SECTION et al.

As a historical note, dwarf2out used to do things the same way that
dwarfout does, but I changed it...

Jason

Re: dwarf2 debug dependent upon GAS?

[Jeffrey A Law]

  In message < 19990221144644.M8783@rjlhome.sco.com >you write:
  > I've had it on my list to examine Dwarf2 debugging for System V.  I'm
  > finding that it seems to depend upon a curiosity of the GNU assembler.
  > Is this accurate?
  > 
  > I'm seeing EGCS (current trunk) generate refences to symbols that don't
  > exist.  There are SECTIONS of that name, but no symbols.  Apparently
  > GAS treat them interchangably.  Is it the intent for these to reference
  > the beginning of the section in this file (i.e. local labels) or the
  > beginning of that section once linked? (without making them global, I
  > don't know how I would synthesize that.)
This sounds vaguely familiar.  I think this has been hashed before on the
egcs lists.  Attempts to change this behavior caused some other set of
assemblers to blow chunks, or relocation problems or something else goofy.

We probably need some way to fine tune this particular behavior.

jeff

dwarf2 debug dependent upon GAS?

[Robert Lipe]

I've had it on my list to examine Dwarf2 debugging for System V.  I'm
finding that it seems to depend upon a curiosity of the GNU assembler.
Is this accurate?

I'm seeing EGCS (current trunk) generate refences to symbols that don't
exist.  There are SECTIONS of that name, but no symbols.  Apparently
GAS treat them interchangably.  Is it the intent for these to reference
the beginning of the section in this file (i.e. local labels) or the
beginning of that section once linked? (without making them global, I
don't know how I would synthesize that.)

$ ./as x.s   
(robertl) rjludi:/home3/negcs/gcc
$ /bin/as x.s
UX:as: ERROR: (EOF):undefined name: .debug_info
UX:as: ERROR: (EOF):undefined name: .debug_abbrev
UX:as: ERROR: (EOF):undefined name: .debug_line
UX:as: ERROR: (EOF):undefined name: .text
(robertl) rjludi:/home3/negcs/gcc
$ grep debug_info x.s
        .section        .debug_info
        .4byte  .debug_info
        .4byte  .debug_info


If it's the intent for them to be local, I can probably just arrange
to have something like:

        .section        .debug_info
.debug_info:
        .section        .debug_abbrev
.debug_abbrev:
        .section        .debug_line
.debug_line:
        .section        .text
.text:


emitted at the top of each file.

Any thoughts?

RJL

Re: dwarf2 debug dependent upon GAS?

[Jeffrey A Law]

  In message < 19990221144644.M8783@rjlhome.sco.com >you write:
  > I've had it on my list to examine Dwarf2 debugging for System V.  I'm
  > finding that it seems to depend upon a curiosity of the GNU assembler.
  > Is this accurate?
  > 
  > I'm seeing EGCS (current trunk) generate refences to symbols that don't
  > exist.  There are SECTIONS of that name, but no symbols.  Apparently
  > GAS treat them interchangably.  Is it the intent for these to reference
  > the beginning of the section in this file (i.e. local labels) or the
  > beginning of that section once linked? (without making them global, I
  > don't know how I would synthesize that.)
This sounds vaguely familiar.  I think this has been hashed before on the
egcs lists.  Attempts to change this behavior caused some other set of
assemblers to blow chunks, or relocation problems or something else goofy.

We probably need some way to fine tune this particular behavior.

jeff

dwarf2 debug dependent upon GAS?

[Robert Lipe]

I've had it on my list to examine Dwarf2 debugging for System V.  I'm
finding that it seems to depend upon a curiosity of the GNU assembler.
Is this accurate?

I'm seeing EGCS (current trunk) generate refences to symbols that don't
exist.  There are SECTIONS of that name, but no symbols.  Apparently
GAS treat them interchangably.  Is it the intent for these to reference
the beginning of the section in this file (i.e. local labels) or the
beginning of that section once linked? (without making them global, I
don't know how I would synthesize that.)

$ ./as x.s   
(robertl) rjludi:/home3/negcs/gcc
$ /bin/as x.s
UX:as: ERROR: (EOF):undefined name: .debug_info
UX:as: ERROR: (EOF):undefined name: .debug_abbrev
UX:as: ERROR: (EOF):undefined name: .debug_line
UX:as: ERROR: (EOF):undefined name: .text
(robertl) rjludi:/home3/negcs/gcc
$ grep debug_info x.s
        .section        .debug_info
        .4byte  .debug_info
        .4byte  .debug_info


If it's the intent for them to be local, I can probably just arrange
to have something like:

        .section        .debug_info
.debug_info:
        .section        .debug_abbrev
.debug_abbrev:
        .section        .debug_line
.debug_line:
        .section        .text
.text:


emitted at the top of each file.

Any thoughts?

RJL