This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
curious check in dwarf2_gen_line_info()
- From: David Mosberger <davidm at napali dot hpl dot hp dot com>
- To: geoffk at redhat dot com
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 29 Dec 2004 01:59:18 -0800
- Subject: curious check in dwarf2_gen_line_info()
- Reply-to: davidm at hpl dot hp dot com
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