[Bug binutils/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387

2014-06-30 Thread nickc at redhat dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=16698

--- Comment #10 from Nick Clifton  ---
Sorry - I still cannot reproduce this problem, even with the object file and
library. :-(  The external symbols that I am pulling in look the same as the
ones you use:

 % readelf --syms ../../arm-eabi/libgcc/libgcc.a | grep uidiv
15:  0 FUNCGLOBAL HIDDEN 1 __aeabi_uidiv

  % readelf --syms ../../arm-eabi/newlib/libc.a | grep abort
15: 20 FUNCGLOBAL DEFAULT1 abort

So I guess it must be a host-specific problem.  Maybe you could run the link
under GDB and find out some more about why the assert is being triggered ?

Cheers
  Nick

-- 
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 gprof/17102] New: Gprof of a multi threaded program using Boost::Signal2 produces an incomplete or wrong profile.

2014-06-30 Thread dgotwisn at newfieldwireless dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=17102

Bug ID: 17102
   Summary: Gprof of a multi threaded program using Boost::Signal2
produces an incomplete or wrong profile.
   Product: binutils
   Version: 2.20
Status: NEW
  Severity: normal
  Priority: P2
 Component: gprof
  Assignee: unassigned at sourceware dot org
  Reporter: dgotwisn at newfieldwireless dot com

Running a multi threaded program built with Boost::Signal2 produces call stack
entries with fewer indices (left hand side) than are indicated by the callee's
(right hand side).

Code was built with G++ gcc (GCC) 4.8.1, gprof GNU gprof version
2.20.51.0.2-5.36.el6 20100205.

In looking at the gprof output of this progrm, the call tree lists 1832 items.

If you look at block 84, for example, it refers to an item 2319.  I have found
at least 10 others that are larger than 1832 in the program.

This code was built with the following set as the last set of options given to
G++: -pg -O0 -fno-inline -fno-omit-frame-pointer
-fno-inline-functions-called-once -fno-optimize-sibling-calls
-fno-default-inline, so no inlining or other relevant optimizations should have
occurred.  Without these, the profile collapses things and looses itself much
earlier.

Here is the block for 84:

---
0.000.00 1997300/1997300
boost::variant,
boost::signals2::detail::foreign_void_shared_ptr,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_>::~variant()
[2319]
[84] 0.00.000.00 1997300
boost::variant,
boost::signals2::detail::foreign_void_shared_ptr,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_,
boost::detail::variant::void_>::destroy_content() [84] XXX I16
0.000.00 2026778/2026778
boost::detail::variant::destroyer::result_type
boost::variant,
boost::signals2::detail::foreign_void_shared_ptr,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_, boost::detail::variant::void_,
boost::detail::variant::void_,
boost::detail::variant::void_>::internal_apply_visitor(boost::detail::variant::destroyer&)
[69]
0.000.00 2023311/2023335
boost::detail::variant::destroyer::destroyer() [70]
0.000.00 1915477/1915501
boost::detail::variant::destroyer::~destroyer() [91]
---

Because this is proprietary code, and I am not a boost expert, I can't easily
attach a code sample that reproduces the problem.

-- 
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/16948] recent binutils/bfd release tarballs generated with ancient autoconf version

2014-06-30 Thread maillist-gdb at barfooze dot de 
https://sourceware.org/bugzilla/show_bug.cgi?id=16948

maillist-gdb at barfooze dot de changed:

   What|Removed |Added

 Blocks||16370

-- 
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/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387

2014-06-30 Thread maillist-gdb at barfooze dot de 
https://sourceware.org/bugzilla/show_bug.cgi?id=16698

--- Comment #11 from maillist-gdb at barfooze dot de ---
according to the contents of the "abfd" variable when the assert is raised,
it's caused by the stdin.o and fflush.o object files in libc.a, which both do
some weak symbol magic to pull in specific functions or data only when they're
actually used.
i'm not fully understanding yet what's happening there...

the code in question is
http://git.etalabs.net/cgit/musl/tree/src/stdio/fflush.c#n23
http://git.etalabs.net/cgit/musl/tree/src/stdio/stdin.c#n15 (variable is
defined here http://git.etalabs.net/cgit/musl/tree/src/stdio/__stdio_exit.c#n4
)

it seems they're getting pulled in via crt1.o -> __libc_start_main -> exit

if i can find a way to get ld to list all the object files it pulls in from
libc.a, i could extract those and attach them here.

-- 
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/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387

2014-06-30 Thread bugdal at aerifal dot cx 
https://sourceware.org/bugzilla/show_bug.cgi?id=16698

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #12 from Rich Felker  ---
For musl libc.a, neither stdin.o nor fflush.o should be pulled in unless
they're actually used. For stdin.o, that means referencing stdin itself or a
function (like scanf or getchar) that explicitly uses stdin. For fflush.o, the
users are assert, getpass, fclose, freopen, and the stdio_ext.h functions. So
this seems wrong:

> it seems they're getting pulled in via crt1.o -> __libc_start_main -> exit

As for:

> if i can find a way to get ld to list all the object files it pulls in from
> libc.a, i could extract those and attach them here.

Won't -Wl,-M do this? Or you could just look at a non-stripped output binary
with debug symbols, which should show the object file filenames that were
linked.

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