Bug 23616 - Unknown signal error from gdb when stepping over musl libc function call using SIGSYNCCALL
Summary: Unknown signal error from gdb when stepping over musl libc function call usin...
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 8.0.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-08 12:29 UTC by Shahar Valiano
Modified: 2019-04-11 13:03 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shahar Valiano 2018-09-08 12:29:04 UTC
In applications linked against musl libc, stepping over calls to the 'setrlimit' library function result with an error from gdb:

    Thread 1 "myprog" recieved signal ?, Unknown signal.
    __cp_end () at src/thread/x86_64/syscall_cp.s:29

Then, it's not possible to continue the debug session beyond that point.

This issue was seen on Alpine Linux, but may be applicable to apps linked against musl libc on other Linux distros as well. Specifically, it is seen when debugging certain versions of OpenJDK and CoreCLR (links 1, 2) (in which the issue is especially troubling since setrlimit is called during VM startup).

The issue stems from the musl libc implementation of setrlimit (link 3). It updates threads in a synchronized manner by calling __synccall (link 4), which signals the threads with a SIGSYNCCALL signal:

    r = -__syscall(SYS_tgkill, pid, tid, SIGSYNCCALL);

SIGSYNCCALL is internal to musl and doesn't seem to be recognized by gdb. When stepping over this code line, gdb intercepts the SIGSYNCCALL signal and reports the "Unknown signal" error.

This signal is defined as follows in musl pthread_impl.h (link 5), along with two other signal types:

    #define SIGTIMER 32
    #define SIGCANCEL 33
    #define SIGSYNCCALL 34

Adding support for these signal types in gdb, at least avoiding the mentioned error, will enable better debugging of OpenJDK and other apps on Alpine Linux.

Tested with:
- Alpine Linux V3.8
- OpenJDK (openjdk7 / openjdk8 package, but any OpenJDK version should be applicable)
- gdb versions 8.0.1-r6, 8.0.1-r3, 7.12.1-r1.

Reproduction:
- gdb <path/to/java>
- r -version

Links:

[1] https://github.com/dotnet/coreclr/issues/7487
[2] https://stackoverflow.com/questions/52119176/gdb-debugging-openjdk-java-on-alpine-linux-fails-with-thread-recieved-signal
[3] http://git.musl-libc.org/cgit/musl/tree/src/misc/setrlimit.c
[4] http://git.musl-libc.org/cgit/musl/tree/src/thread/synccall.c
[5] http://git.musl-libc.org/cgit/musl/tree/src/internal/pthread_impl.h
Comment 1 Shahar Valiano 2019-04-11 13:03:03 UTC
I've implemented a quick and dirty patch for musl signals, for reference:

https://github.com/shaharv/binutils-gdb/commit/0ca9c66889bdc9558622a92f96a86552fa701924

The trouble is, the three mentioned musl signals are internal and not defined in the user facing <signals.h>, so I had to define them locally. There's also no __MUSL__ define, so another difficulty is ifdef'ing these defines to be for musl builds only.