Bug 12974 - ld "undefined reference" shows wrong line number
Summary: ld "undefined reference" shows wrong line number
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.20
: P2 normal
Target Milestone: ---
Assignee: unassigned
Depends on:
Reported: 2011-07-08 15:21 UTC by Jonny Grant
Modified: 2011-08-01 11:27 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

Sample build that illustrates the issue (978 bytes, application/zip)
2011-07-08 15:21 UTC, Jonny Grant
Add DWARF" line number information to literal pool entries. (788 bytes, patch)
2011-07-12 12:37 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonny Grant 2011-07-08 15:21:10 UTC
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 --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

arm-none-eabi-ld --version
GNU ld (Sourcery G++ Lite 2010.09-51)
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
Comment 1 Nick Clifton 2011-07-12 12:37:16 UTC
Created attachment 5843 [details]
Add DWARF" line number information to literal pool entries.
Comment 2 Nick Clifton 2011-07-12 12:41:01 UTC
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

  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

  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.

Comment 3 Jonny Grant 2011-07-31 22:51:23 UTC
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
Comment 4 cvs-commit@gcc.gnu.org 2011-08-01 11:27:18 UTC
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.

Comment 5 Nick Clifton 2011-08-01 11:27:56 UTC
Patch committed.