This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: allow gas to emit duplicate line numbers
- From: Michael Snyder <msnyder at redhat dot com>
- To: Sue Ludwig <sue_ludwig at hp dot com>
- Cc: binutils at sources dot redhat dot com, ipdl-tools-gnu at cup dot hp dot com, geoffk at redhat dot com, nickc at cambridge dot redhat dot com
- Date: Fri, 16 Aug 2002 17:52:18 -0700
- Subject: Re: allow gas to emit duplicate line numbers
- Organization: Red Hat, Inc.
- References: <000701c2457a$def6fb50$ce60000f@HPPDL632>
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