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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
