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. C:\test>make arm-none-eabi-gcc --version 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. arm-none-eabi-ld --version GNU ld (Sourcery G++ Lite 2010.09-51) 2.20.51.20100809 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.
Hi Jon, 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 work. Right, now the real problem. The thing is, the line number is correct. Sort of... What is happening is that the: LDR R1,=missing_global_buffer 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 12). 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 .ltorg 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 process. 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. Cheers Nick
Hi Nick 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. Regards, Jon
CVSROOT: /cvs/src Module name: src Changes by: nickc@sourceware.org 2011-08-01 11:27:14 Modified files: gas : ChangeLog gas/config : tc-arm.c Log message: PR ld/12974 * 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. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.4555&r2=1.4556 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-arm.c.diff?cvsroot=src&r1=1.498&r2=1.499
Patch committed.