allow gas to emit duplicate line numbers

Michael Snyder msnyder@redhat.com
Fri Aug 16 18:09:00 GMT 2002


Sue Ludwig wrote:
> 
> Hi,
> 
> In version 1.45 of dwarf2dbg.c, the function dwarf2_gen_line_info has the
> following code:
>   if (debug_type == DEBUG_DWARF2
>       && line == loc->line && filenum == loc->filenum)
>     return;
> 
> This use to be:
>   if (line == loc->line && filenum == loc->filenum)
>     return;
> 
> I see from the emails and cvs that this change was done so that duplicate
> line symbols are emitted for GDB to determine the end of the prolog.

The story's a bit more complicated than that.  There are two situations:
1) GCC emits duplicate line symbols in the prologue.
   This is good -- we want to keep those.
2) GAS emits duplicate line numbers when you ask it to emit
   debug information for assembly source files (so you can
   debug them as source files).  This is bad, and we want
   to get rid of those.

I added the simpler test (if line == loc->line and file == loc->file)
to eliminate #2, the duplicate line symbols from GAS.  Unfortunately, 
that also eliminated #1, the duplicate line numbers from GCC.  So
NickC expanded my conditional to include DEBUG_DWARF2, which should
only be true if the assembler itself is generating the line symbols.

> On HPUX on IPF, duplicate line symbols will confuse GDB unless they are
> flagged as not statements, i.e. DW_LNS_negate_stmt is emitted for the
> duplicate lines.  When these duplicate lines are flagged as statements, GDB
> thinks that the prolog ends before it actually does.

I take it these duplicate line symbols are being generated by
gcc?  If so, the above code
should not affect them at all, because debug_type should not be
equal to DEBUG_DWARF2.


> I could bypass this change by setting the debug_type to equal DEBUG_DWARF2,
> by passing --gdwarf2 to the assembler. 

No no no -- bad thing to do.  You need to find out why the compiler
is generating these duplicate line numbers.  If they are the normal
duplicates associated with the prologue, then there is something 
wrong with gdb.


> However after doing this, when I set
> a breakpoint, gdb uses the line numbers in the assembler file (*.s) instead
> of the source file (*.c).  

That's what you told it to do, by sending --gdwarf2 to the assembler.
This effectively makes the assembly file a source file.

[snip]
> 
> My questions are:
> 1. Can the code change in version 1.45 be done differently so that when
> debug_type == DEBUG_UNSPECIFIED, the return will occur, as it does for
> DEBUG_DWARF2?

Nope.  This code is explicitly -not- supposed to touch line symbols
generated by the compiler.  Find out why they are there.  Either they
are bad, or they are good and gdb is bad.  It's not gas's fault.
(And I say so as a gdb maintainer, so it's not in my best interest).


> If not, can the following be done:
> 
> 2. Can DW_LNS_negate_stmt be generated for the duplicate lines allowed in
> the prolog when debug_type != DEBUG_DWARF2?

I don't think so, because you don't want to get rid of those.

> 3. Code in dwarf2_where be modified so that *line = current even when
> debug_type == DEBUG_DWARF2?  Otherwise the line information is based on the
> assembler file and not the source file.

That's what is supposed to happen.  Don't send --gdwarf2.


> 4. If we are not putting in the line generated by the assembler in the line
> table when debug_type == DEBUG_DWARF2, why are we putting in assembler
> generated information in the .debug_info and .debug_abbrev sections in
> dwarf2_finish?

We are putting in the line generated by the assembler -- just not the
duplicate lines.

Best,
Michael Snyder



More information about the Binutils mailing list