This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: Compiler emitting .debug_line versus binutils
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Will Newton'" <will dot newton at imgtec dot com>, <binutils at sourceware dot org>
- Date: Fri, 29 Jun 2007 15:48:45 +0100
- Subject: RE: Compiler emitting .debug_line versus binutils
- References: <0D107966AF6D79418315B7C5549F4B516432EC@lemail1.le.imgtec.org>
On 29 June 2007 15:35, Will Newton wrote:
> Hi all, I have a binutils 2.17 port and a gcc 2.95.3 port for an embedded
> DSP type chip. The compiler spits out a .debug_line section in the
> assembler code like this: .section .debug_line
> .4byte 0xab .2byte 0x2 .4byte 0x1b .byte 0x4
> .byte 0x1 .byte -10 .byte 245 .byte 10
> ... This seems to be done by dwarf2out_finish() in dwarf2out.c inside gcc.
> I assemble the result with gas, which then outputs another .debug_line
> section in dwarf2_finish() in dwarf2dbg.c. This results in a rather
> strabge looking .debug_line section in the final executable.
What's strange-looking about it? That's exactly what they're supposed to
look like.
> Can anyone
> tell me how this should be resolved?
It doesn't need resolving, it is correct.
> There doesn't seem to be any obvious
> way to tell gas not to emit the .debug_line section.
Don't compile with -g and gcc won't emit a .debug_line section as a result
of which gas won't assemble a .debug_line section. There is no switch to tell
gas to randomly not assemble some of the source code you feed it, you're
expected to not feed it stuff you don't want it to assemble.
( Alternatively, fix your linker script. You haven't actually said what the
problem is, but my guess is you're worried it will be loaded into memory at
runtime. It's debugging info and doesn't need to be loaded; your linker
script should throw it all away in a DISCARD section. )
cheers,
DaveK
--
Can't think of a witty .sigline today....