[Bug gdb/23616] Unknown signal error from gdb when stepping over musl libc function call using SIGSYNCCALL

[Bug gdb/23616] Unknown signal error from gdb when stepping over musl libc function call using SIGSYNCCALL

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |simark at simark dot ca
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-12-07

--- Comment #4 from Simon Marchi <simark at simark dot ca> ---
>From what I understand, GDB (when debugging natively, replace with GDBserver
for the remote case, but I'll just use GDB for simplicity) assumes that it sees
the same signal numbers as the program it debugs.  For all I know this is
always true, since it runs on the kernel as the program it debugs.  If we
couldn't rely on that, i.e. if signal numbers in the inferior could be
different than the signal numbers as seen by GDB, then I suppose we would need
to bake in GDB the knowledge of all signal numbers for all platform.  Or, there
would need to be some sort of debug API for GDB to ask "what does this signal
mean in the context of this process"?

This real-time signal issue looks like a bug in GDB.  Basically,
gdbsupport/signals.cc wants to know what is the min and max real-time signal
numbers provided by the OS, not the min/max shown by the libc.  It doesn't care
that 2 or 3 real-time signals are reserved by the libc.  This is why it tries
to use __SIGRTMIN if possible: on glibc that passes through the SIGRTMIN value
exposed by the kernel.  Since musl doesn't have __SIGRTMIN, GDB falls back on
using SIGRTMIN (35 with musl) so it thinks that the lower real-time number
offered by the OS is 35, which is wrong.  GDB should see 32 here.  Falling back
on SIGRTMIN may be ok for systems where the libc doesn't reserve any signal
numbers for itself, but that's not right here.

There is already the intention of providing __SIGRTMIN when compiling on Linux
with a libc that doesn't provide __SIGRTMIN:

https://github.com/bminor/binutils-gdb/blob/13f11b0b61ca2620611b08eeaece0ce62c862f4b/gdb/nat/linux-nat.h#L29-L32

But this is currently just used to make the gdb/linux-nat.c code (which uses
__SIGRTMIN) build on those platforms.  gdb/nat/linux-nat.h isn't included by
gdbsupport/signals.cc.

So, clearly, there is something to fix in GDB so that gdbsupport/signals.cc
sees the SIGRTMIN value as provided by the kernel.  But I can't think of a nice
solution right now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.