Bug 31327 - libbacktrace test failures
Summary: libbacktrace test failures
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-02 07:21 UTC by Sam James
Modified: 2024-03-11 23:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James 2024-02-02 07:21:26 UTC 
Configured binutils-2.42 at 7e4f6dd4e6ef2d6c5d7929bb90364d7bff887c27 on binutils-2_42-branch with:
```
$ ./configure --prefix=/tmp/bisect --disable-gdb --disable-libdecnumber --disable-readline --disable-sim && make -j$(nproc) && make -j$(nproc) check
```

The libbacktrace testsuite fails its mtest_minidebug test for me: 
```
FAIL: mtest_minidebug
=====================

test1: [0]: syminfo did not find name
test1: [1]: syminfo did not find name
test1: [2]: syminfo did not find name
test1: [0]: missing function name
test1: [1]: missing function name
test1: [2]: missing function name
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
test5: NULL syminfo name
FAIL: backtrace_full noinline
FAIL: backtrace_simple noinline
FAIL: backtrace_syminfo variable
FAIL mtest_minidebug (exit status: 1)
```

I can hit the same on binutils-2.41_release so I guess something else changed (either glibc-2.39 or gcc 14).

I notice our copy of libbacktrace looks a bit stale comapred to the one in gcc - maybe needs a sync?
Comment 1 Sam James 2024-02-02 07:29:25 UTC 
If I blindly copy in libbacktrace, it doesn't help, so let me investigate a bit more then report it to GCC if it continues.
Comment 2 Sam James 2024-03-07 12:36:18 UTC 
OK, I get what's happening here. 

This ended up being https://github.com/ianlancetaylor/libbacktrace/issues/118 which is fixed upstream.

Nick, or Ian, could we sync the version in binutils-gdb.git with upstream please? I am happy to do it with permission too.
Comment 3 Ian Lance Taylor 2024-03-07 13:34:38 UTC 
It's fine with me.  I don't know if there is any binutils policy about this.
Comment 4 Nick Clifton 2024-03-08 12:12:28 UTC 
(In reply to Sam James from comment #2)
> OK, I get what's happening here. 
> 
> This ended up being
> https://github.com/ianlancetaylor/libbacktrace/issues/118 which is fixed
> upstream.
> 
> Nick, or Ian, could we sync the version in binutils-gdb.git with upstream
> please? I am happy to do it with permission too.

I can.  But I would rather one of the GDB global maintainers did it, since gdb is the consumer of libbacktrace.  If you do not get a response from them however please ping me and I will take care of it.


(In reply to Ian Taylor from comment #3)
> I don't know if there is any binutils policy about this.

I think that we should consider libbacktrace to be the same as libiberty or config.  Ie something that we sync from gcc.  In fact we should probably add that to the top-level MAINTAINERS file...
Comment 5 Sam James 2024-03-08 22:26:11 UTC 
Thank you both. Done at https://inbox.sourceware.org/gdb/87plw4r5ta.fsf@gentoo.org/T/#u.
Comment 6 Sam James 2024-03-11 23:19:57 UTC 
commit b450e102730c527ec3b7164b119362a15ce545e6 (upstream/master)
Author: Sam James <sam@gentoo.org>
Date:   Mon Mar 11 17:21:07 2024 +0000

    Sync libbacktrace from gcc [PR31327]

    Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which
    landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC.

    This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk.

    Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b
    which would've required an autoreconf, as it should be handled separately.

    Approved-By: Tom Tromey <tom@tromey.com>