RE: allow gas to emit duplicate line numbers

["Sue Ludwig" <sue_ludwig at hp dot com>]

Hi,

I have discovered another problem with using --gdwarf2.  Take the test case:
#include <stdio.h>
int main() {
   return 0;
}

Using the compile command on Linux/IPF or HPUX/IPF:
gcc -g -Wa,--gdwarf2 main.c
Produces the error:
/tmp/cc0rD6Kk.s: Assembler messages:
/tmp/cc0rD6Kk.s:30: Error: file number 2 already allocated

If the test case is modified to:
int main() {
   return 0;
}

Then there is no error during compilation for Linux/IPF or HPUX/IPF.
However, the debugging errors I reported below are still there.

Given that there seems to be further problems with passing --gdwarf2 to the
assembler, implementing what I have suggested below in questions 3 and 4 may
not be enough. Implementing what I have suggested below in question 1 would
be my preference.  Failing that I would like to see what I'm suggesting
below in question 2 implemented.

Regards,
Sue Ludwig

> -----Original Message-----
> From: Sue Ludwig [mailto:sue_ludwig@hp.com]
> Sent: Friday, August 16, 2002 4:16 PM
> To: binutils@sources.redhat.com
> Cc: ipdl-tools-gnu@cup.hp.com; geoffk@redhat.com; msnyder@redhat.com;
> nickc@cambridge.redhat.com
> Subject: Re: allow gas to emit duplicate line numbers
>
>
> 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.
>
> 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 could bypass this change by setting the debug_type to equal
> DEBUG_DWARF2,
> by passing --gdwarf2 to the assembler.  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).  This is due to code in
> dwarf2_where (or line 263
> of dwarf2dbg.c), where instead of *line = current the other code is
> executed.  This occurs in Linux on IPF as well.
>
> Another problem with passing --gdwarf to the assembler on
> HPUX on IPF is the
> offsets into some sections are calculated incorrectly.  The code is in
> dwarf2_finish (or line 1273 of dwarf2dbg.c).  Again code within the if
> (all_segs != NULL && debug_type == DEBUG_DWARF2) is executed.
>  Some of the
> errors that I'm seeing when using gdb on the executable are:
> a. Dwarf Error: bad offset (0xa8) in compilation unit header
> (offset 0x65 +
> 6)
> b. the offset in DW_FORM_strp is past the end of the
> .debug_str section.
>
> Note: The code in dwarf2_where and dwarf2_finish were added
> in version 1.20
> of dwarf2dbg.c.
>
> 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?
>
> 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?
>
> 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.
>
> 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?
>
> Regards,
> Sue Ludwig
>
>