Created attachment 5839 [details]
Sample build that illustrates the issue
output from ld shows the wrong line number for an "undefined reference". as my tools are not so recent (codesourcery), would someone be able to confirm if
this issue is reproducible if possible please.
The line number 19 is the last symbol in the start.S. void main(void)
function does exist in the build as well. Possibly is this the debug
info that is incorrect in the start.o file?
I attach my sample assembler file and build commands, which is for ARM.
arm-none-eabi-gcc.exe (Sourcery G++ Lite 2010.09-51) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
GNU ld (Sourcery G++ Lite 2010.09-51) 220.127.116.1100809
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
arm-none-eabi-gcc -g start.S main.c -o test.elf
c:\tmp\cckh49E5.o: In function `go_main':
C:\test/start.S:18: undefined reference to `missing_global_buffer'
collect2: ld returned 1 exit status
make: *** [all] Error 1
Created attachment 5843 [details]
Add DWARF" line number information to literal pool entries.
This is more of a mis-feature than a bug...
But first, a quick note about the gcc command in the makefile that
you uploaded in sample build. You need to add the "-nostartfiles"
command line option to the last line, in order to get the build to
Right, now the real problem. The thing is, the line number is
correct. Sort of... What is happening is that the:
instruction at line 12 of start.S is causing a reference to the
symbol "missing_global_buffer" to be put into the literal pool. The
LDR instruction then loads this address out of the pool. The pool
itself is automatically dumped by the assembler at the end of the
assembled instructions, ie at the equivalent of line 18. Hence when
the error message is displayed it refers to the entry in the pool
(line 18), not the LDR instruction that makes use of the pool (line
If there were multiple LDR instructions referring to the same
symbol, there would still be only one error message, because the
address of missing_global_symbol is only used in place - the pool.
You could force the literal pool to be dumped just after the LDR instruction, if you wanted to. Eg:
LDR R1,=missing_global_buffer ; b go_main
But I doubt if this is what you really want. I cannot think of a
simple way to give you the behaviour you desire. In order to locate
the line(s) that refer to the entry in the literal pool the entire
program would have to be searched looking for LDR instructions, and
then the addresses of these instructions would have to be converted
into file names/line numbers. This would be quite a time consuming
Note - if you had multiple, different, missing symbols in your
start.S file, they will all appear to come from the same line
number, because the literal pool is only associated with a single
line in the source file. Also because a single literal pool entry
can be referenced from multiple places in the source code there can
be more than one source line associated with that entry, and this is
something that cannot be expressed in DWARF2 debugging information.
I have uploaded a patch that partially solves the problem. It
associates a DWARF2 line number with each entry in the literal
pool. This line number is the line in the source code that caused
the entry to be created. If there are other references to this
entry from other places in the source code then they will be
ignored. Ie if there are multiple references to the same undefined
symbol, only the line number of the first reference will be
displayed in the error message.
Please have a go with the patch and let me know what you think.
Thank you for your update with anyalysis and also the patch.
Unfortunately I don't have time to test the patch as I'm overloaded currently. Perhaps the change can simply be committed if working well.
Module name: src
Changes by: email@example.com 2011-08-01 11:27:14
gas : ChangeLog
gas/config : tc-arm.c
* config/tc-arm.c (literal_pool): Add locs field.
(add_to_lit_pool): Initialise the locs entry for the new literal.
(s_ltorg): Generate a DWARF2 line number entry for each emitted
literal pool entry.