[Bug ld/12974] ld "undefined reference" shows wrong line number

[nickc at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12974

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> 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
  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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.