[Bug binutils/19315] New: addr2line change for C++ symbols breaks behavior for inlined functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19315

Bug ID: 19315
   Summary: addr2line change for C++ symbols breaks behavior for
inlined functions
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: pcarroll at codesourcery dot com
  Target Milestone: ---

Created attachment 8818
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8818&action=edit
C++ test case

This issue is a side effect of the change for bug #17541
(https://sourceware.org/bugzilla/show_bug.cgi?id=17541).
That change was to have addr2line (through the use of BFD dwarf2.c) identify
C++ symbols in debug information that could be missing namespace, class, and
other information but have no linkage name, and then find a matching symbol in
the ELF symbol table.

I compiled my enclosed test case with g++ 5.2.0, with the '-g -O2' options, for
ARM Linux.
I then inspected the DWARF2 information for my resulting executable and found
the debug information for my 'main' subprogram.  The DWARF2 information then
showed 2 following inlined functions.  The first inlined function mapped to the
'func1' class member, which had a linkage name of '_Z5func1i'.  The second
inlined function mapped to the 'myfunc' C function, which has no linkage name. 
In my example, the low_pc address for 'myfunc' is 0x103cc.  
(I'm not sure there is a way to figure out the appropriate address without just
inspecting an executable.  So, of course, I would expect a different address
for a test case compiled with a different toolchain.)
With that in mind, I run addr2line 2.25.51 on the resulting executable, with
the arguments '-f -i -e addr2test2 103ce', so it maps into the innermost
function.  This produces the following output:

main
/bug/addr2test2.h:4
_Z5func1i
/bug/addr2test2.cpp:23
main
/bug/addr2test2.cpp:32

As we can see, this returns the name of the outermost function 'main' rather
than the innermost function 'myfunc' for the first function name.

When I investigated this issue, I believe it ties into the code at the end of
'_bfd_dwarf2_find_nearest_line'.  There, the code checks if is_linkage is set
for a function.  If not (i.e., it is C++ or similar), then a call to
'_bfd_elf_find_function' is made.  That will find a symbol in the ELF symbol
table, which is, of course, the outermost function name.  The inlined function
names are not found by this means.  That is not a problem if the linkage name
is present.  But that is not always the case, such as for an inlined C
function, as occurred here.  

I believe this can be avoided by modifying '_bfd_elf_find_function' in
dwarf2.c, to have it return a pointer to the symbol that is found.  Then, after
'_bfd_elf_find_function' is called for symbols without a linkage symbol, the
value of the ELF symbol is compared against the DWARF's low_pc value.  The test
I used was:

if ((matching_sym->value+section->vma) == function->arange.low)

I'm not sure if that is the best way to see if these addresses are the same,
but that worked for me.  If the addresses are the same, then using the ELF
symbol is appropriate.  If the addresses are different, though, then the DWARF2
symbol is appropriate.  That is true whether the symbol is an embedded C
function, such as is my example, or it is a C++ symbol that has no linkage name
and is somehow missing namespace, class, or other information.  Some
information seems better than wrong information.

When I ran my modified addr2line function, I got the following output:

myfunc
/bug/addr2test2.h:4
_Z5func1i
/bug/addr2test2.cpp:23
main
/bug/addr2test2.cpp:32

That, I think, is the best we can hope for.
And that also matches what is seen with addr2line 2.24.51.

-- 
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

[Bug binutils/19315] addr2line change for C++ symbols breaks behavior for inlined functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19315

--- Comment #1 from Paul Carroll  ---
If it would be useful, I can attach the 10k executable that I created from
compiling my test case.  I would presume the test case could be compiled for
any target with g++ 5.2.0 to demonstrate this issue.  Thanks...

-- 
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

[Bug binutils/19315] addr2line change for C++ symbols breaks behavior for inlined functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19315

--- Comment #4 from Paul Carroll  ---
Created attachment 8828
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8828&action=edit
Executable compiled for ARM Linux with G++ 5.2.0

-- 
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

[Bug binutils/19315] addr2line change for C++ symbols breaks behavior for inlined functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19315

--- Comment #7 from Paul Carroll  ---
Thanks, Alan.  
I tried the patch on several test cases and they behaved as expected.

-- 
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

[Bug binutils/17512] libbfd/binutils: crashes on fuzzed samples

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17512

Paul Carroll  changed:

   What|Removed |Added

 CC||pcarroll at codesourcery dot 
com

--- Comment #233 from Paul Carroll  ---
If I may say so, I believe the issue of synthetic symbols is not being handled
correctly by the patch here.
The 'is_synthetic' flag was added to 'print_symbol()'.
The flag itself is set in 'print_size_symbols()' and 'print_symbols()' by just
deciding that the last 'synth_count' symbols in the list are synthetic.
However, since there are 2 different methods of sorting these symbols, either
with the 'qsort()' or the call to 'sort_symbols_by_size()', it is unlikely that
the last 'synth_count' symbols of each sort will all be synthetic.
There is also the added call to 'filter_symbols()' before the sorts, which may
or may not remove synthetic symbols, while not adjusting the 'synth_count'
value.
(If no synthetic symbols are filtered, then there is no harm - I haven't looked
at the filter function yet)

In my opinion, it makes more sense to remove the 'from >= fromsynth' from the
calls to 'print_symbol()' and 'print_size_symbols()', since the last
'synth_count' symbols are not going to be synthetic.
Likewise, 'print_symbols()' can drop the 'is_synthetic' argument.
Instead, the symbol's flag can be tested to see if BSF_SYNTHETIC is set.
By doing that, the position of the symbol in the sorted list is irrelevant.

I am assuming that only synthetic symbols are being created with the
BSF_SYNTHETIC flag set.  That seems to match the code in the bfd directory.

-- 
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

[Bug binutils/21266] New: Unstable qsort in bfd/elf64-ppc.c results in difference in ld's TLS opt 3 test on Windows

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21266

Bug ID: 21266
   Summary: Unstable qsort in bfd/elf64-ppc.c results in
difference in ld's TLS opt 3 test on Windows
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: pcarroll at codesourcery dot com
  Target Milestone: ---

The qsort() routine is noted to be unpredictable if 2 compared objects are
considered equal.  The 'compare_symbols' function in the bfd/elf64-ppc.c file
compares attributes of various symbols up to a point.  Where there can be a
problem is if there are 2 symbols with different names, but identical
attributes.  In this case, the current definition of 'compare_symbols' just
does a:
 return 0;
at the end of the function.  This, however, results in different behavior in
the TLS opt 3 testcase of the linker when the test suite is run on different
OSes.  A standard was created for that test case on Linux.  When this is run on
a Windows system, however, the test fails:

regexp_diff match failure
regexp "^10e8 <\.__tls_get_addr>:$"
line   "10e8 <.__tls_get_addr_opt>:"
regexp_diff match failure
regexp "^.*:(4b ff ff ed|ed ff ff 4b)   bl  10e8
<\.__tls_get_addr>$"
line   "10fc:   4b ff ff ed bl  10e8 <.__tls_get_addr_opt>"
regexp_diff match failure
regexp "^.*:(4b ff ff e1|e1 ff ff 4b)   bl  10e8
<\.__tls_get_addr>$"
line   "1108:   4b ff ff e1 bl  10e8 <.__tls_get_addr_opt>"

To get predictable results between Linux and Windows, the last line of
'compare_symbols' should be changed to be:
 return strcmp(a->name,b->name);
With that change, if symbols have different attributes, then they continue to
be handled as before.
If, however, symbols are identical except for having different names (i.e., 2
symbols referring to the same location), then that will allow qsort() to
produce identical output for different OSes.

-- 
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

[Bug binutils/22771] New: nm does not display line information for uninlined copies of functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22771

Bug ID: 22771
   Summary: nm does not display line information for uninlined
copies of functions
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: pcarroll at codesourcery dot com
  Target Milestone: ---

Created attachment 10768
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10768&action=edit
Possible patch to nm for this issue

The nm utility supports -l for using debug information to obtain file and line
information for each symbol.
When a source is compiled with -O2, functions can be inlined.  The compiler
also produces an uninlined copy of the function, normally for use by other
files.
In the case of DWARF2 debug information, the compiler generates debug
information to describe the function.  It then references that debug
information from the inlined and uninlined copies of the routine through the
use of the DW_AT_abstract_origin reference.  
When nm is used on such a file, it is not able to find file and line
information because that information is present at the common debug information
and not at each actual implementation of the function.

What I am proposing is to modify the find_abstract_instance_name() function
(which I renamed to find_abstract_instance() ) to return the name of the
function as well as file and line information.  The routine is already parsing
all of the debug information in the abstract instance, so it is easy to pick up
the file and line information at that time.  

For example, if I have a simple test case:

int foo(int j)
{
if (j < 15)
j += j << 2;
else if (j < 30)
j += j << 4;
else
j += j << 6;
return j;
}

int main (int argc,char **argv)
{
int i = argc;
i += foo(i);
return i;
}

If that test case is compiled and then 'nm -l' reads that executable, it
currently produces this symbol output (ignoring a lot of library symbols):

8048400 T foo
080482e0 T main /scratch/pcarroll/its254/test/mytest.c:12

If I modify 'nm' to return file and line information for abstract instances, it
produces the following output:

08048400 T foo  /scratch/pcarroll/its254/test/mytest.c:1
080482e0 T main /scratch/pcarroll/its254/test/mytest.c:12

I am attaching my proposed patch.

-- 
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

[Bug binutils/22771] nm does not display line information for uninlined copies of functions

[pcarroll at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22771

--- Comment #1 from Paul Carroll  ---
Just to reduce possible confusion, when my previous comment says:

If that test case is compiled and then ...

I am implying

If that test case is compiled with -O2 and then ...

The '-O2' option is needed so inlining occurs.

-- 
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

[Bug ld/12768] Improve the error message for linking failure

[pcarroll at codesourcery dot com]

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

Paul Carroll  changed:

   What|Removed |Added

 CC||pcarroll at codesourcery
   ||dot com

--- Comment #1 from Paul Carroll  2011-05-16 
14:14:38 UTC ---
I worked on one solution for this issue last month.  The method I used was to
just make a list of external symbols for each input object (just a linked list
that points to the symbol entries in the hash table).  Then, when the error is
detected and it is time to emit a message, I just went through the list of
input objects and scanned each list of external symbols, looking for the symbol
entry that matches the entry for the hidden symbol.  They are one and the same.
 Once I find a matching symbol, I know which object file contained the
reference to the hidden symbol and could just print the name of that DSO.  

As noted, there is a small amount of overhead during the processing of input
files, to create the lists, but the overhead is a 4-byte pointer to the list
and then 8 bytes for each external symbol.  As an alternative, since this
message doesn't occur too often, a linker option could be added and the
original error message modified so the user just has to do one extra link to
identify the name of the DSO.  

There are other methodsfor solving this problem, such as reopening all input
objects and checking them for an external symbol matching the hidden symbol. I
just choose a solution that did not require a lot of changes to the BFD
library.  

My patch hasn't been reviewed yet, so it is not yet merged into the latest
Binutils trunk.

-- 
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

[Bug ld/12768] Improve the error message for linking failure

[pcarroll at codesourcery dot com]

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

--- Comment #3 from Paul Carroll  2011-05-18 
10:47:55 UTC ---
No, Nick, I haven't submitted any kind of patch or such as yet.  I was waiting
on an internal company review first, before sending the fix upstream.  Your
comment about tying the reduced-memory option into whether the symbols are
stored sounds reasonable.  Odds are that it will become part of the patch.

-- 
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