This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

curious check in dwarf2_gen_line_info()


[Resend^2: I mistakenly typed .com instead of .org for his domain... ;-( ]

In dwarf2dbg.c:dwarf2_gen_line_info(), one finds this curious code and
comment:

  /* Don't emit sequences of line symbols for the same line when the
     symbols apply to assembler code.  It is necessary to emit
     duplicate line symbols when a compiler asks for them, because GDB
     uses them to determine the end of the prologue.  */
  if (debug_type == DEBUG_DWARF2
        && line == loc->line && filenum == loc->filenum)
    return;

The "debug_type == DEBUG_DWARF2" checks has the effect that for
compiler-generated files, the line info is replicated for each
instruction, even when that info doesn't change at all.

The change seems to have been introduced back in 2002:

  2002-04-17  Geoffrey Keating  <geoffk@redhat.com>
        * dwarf2dbg.c (dwarf2_gen_line_info): Do emit duplicate line
        numbers, gdb relies on them to detect the start of the prologue.

but there is no hint on which platform needed this workaround.

I looked at gdb's symtab.c:skip_prologue_using_sal() and as near as I
can tell, that doesn't rely on having duplicate line-info.

To evaluate the size impact of the line-info duplication, I compiled a
fairly large Linux kernel file (sched.c).  For that file, the
.debug_line size changed as follows:

	original gas:	0x3b93 (+46%)
	fixed gas:	0x28cd

So the workaround bloats the .debug_line section by almost 50%.

Is there a platform which really needs this workaround?  If so,
perhaps the workaround could be enabled for that platform only?

Thanks,

	--david


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]