This test case starts failing since this build https://ci.freebsd.org/job/FreeBSD-head-amd64-test/15169/
Still need to check which commit caused this.
/usr/src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:93: nptrs >= ncalls + 2 + min_frames not met
got nptrs=17 ncalls=12 (min_frames: 4, max_frames: 9)
A commit references this bug:
Date: Mon May 18 12:36:29 UTC 2020
New revision: 361210
Temporarily disable failing case in CI of amd64:
Sponsored by: The FreeBSD Foundation
After more testing, it starts failing on amd64 after https://svnweb.freebsd.org/changeset/base/360915
i386 is not affected.
I suspect r360915 is just wrong and should be reverted. We're missing the frame below /above atf_tc_run (probably "_start" and "main").
$ nm crt1.o:
0000000000000000 T _start
If we had one more frame (_start or main), the test would be:
18 >= 12 + 2 + 4 (pass).
(Our backtrace / libexecinfo (llvm-libunwind) relies on asynchronous unwind tables and does not know about frame pointers. Sure, maybe it should! That would be nice.)
(In reply to Conrad Meyer from comment #3)
This was done to fix bug 246322. As explained there, it is to work around a BFD ld assertion or bug. I'm fine with reverting, as long as we either fix BFD ld, or ban the use of it. :)
(In reply to Dimitry Andric from comment #6)
> work around a BFD ld assertion or bug.
For more explanation see base r209294. It still hits the assertion with binutils master as of last week.
We switched to both ld.lld and llvm-libunwind in CURRENT, so maybe leave it be in stable/ and just revert in CURRENT?
> places the special CIE into the .eh_frame indicating the end of section,
> that is located before generated unwind table. New ld has assertion that
> verifies that closing CIE is indeed the last CIE,
Would it be possible to (?)fix LLVM to not mark the CIE as end of section? I guess I'm unclear on if ld.bfd's assertion is reasonable or what. Why doesn't this happen for other objects built with async unwind tables?
(In reply to Conrad Meyer from comment #9)
Maybe, but I'm not sure that is the right way to go. In base r209294 the problem in BFD ld was first spotted, and at that time it was likely triggered by newer versions of gcc. But kan@ may know a bit more about this.
E.g. with the information I have now, I think this is a BFD ld bug/misfeature, and it should be fixed there.
Any idea why this trips for crt1.o but not any other .o?
(In reply to Conrad Meyer from comment #11)
You mean the ld.bfd assertion? Maybe it is because crt1.o is linked using -r from crt1_c.o and crt1_s.o?
(In reply to Dimitry Andric from comment #12)
Yep, the ld.bfd assertion.
Trips exactly what ?
crt1.o is specially added to the linker command line to create the final binary. It mist go first among all object files supplied to the linker.
(In reply to Konstantin Belousov from comment #14)
Trips bug 246322:
> /usr/bin/ld: error in /usr/lib/crt1.o(.eh_frame); no .eh_frame_hdr table will be created.