Page MenuHomeFreeBSD

gdb(4): fix x86 signal reporting
ClosedPublic

Authored by mhorne on Dec 16 2020, 8:55 PM.

Details

Summary

The existing values correspond to x86 exception vector numbers, but the
trap numbers used in the kernel do not match these 1-to-1. Prefer the
definitions from x86/trap.h, as they are what actually get passed to
kdb_trap(). This is of little consequence, as gdb_cpu_signal() only
reports the trap reason (signal number) to the gdb client.

I have limited this to the subset of trap values for which kdb_trap() is
reachable.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 35455
Build 32365: arc lint + arc unit

Event Timeline

This looks reasonable.

Note that userspace is much more selective/picky about signals delivered in response for traps, but it probably does not matter for gdb stub.

This revision is now accepted and ready to land.Dec 17 2020, 12:51 AM

FWIW, in the bhyve stub, I just always return '5' (SIGTRAP). Note that the signal numbers returned are defined in GDB's source and aren't necessarily FreeBSD signal number values. See the last sentence in the first paragraph here:

https://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets

The actual values are in signals.def:

https://github.com/bsdjhb/gdb/blob/master/include/gdb/signals.def.

Not sure if in gdb(4) we are using some kind of translation table around gdb_cpu_signal to map FreeBSD signal numbers to GDB signal numbers, but that is probably the best way to fix that if needed. For userland we do this here:

https://github.com/bsdjhb/gdb/blob/master/gdb/fbsd-tdep.c#L1727

In D27645#618106, @jhb wrote:

FWIW, in the bhyve stub, I just always return '5' (SIGTRAP). Note that the signal numbers returned are defined in GDB's source and aren't necessarily FreeBSD signal number values. See the last sentence in the first paragraph here:

https://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets

The actual values are in signals.def:

https://github.com/bsdjhb/gdb/blob/master/include/gdb/signals.def.

Not sure if in gdb(4) we are using some kind of translation table around gdb_cpu_signal to map FreeBSD signal numbers to GDB signal numbers, but that is probably the best way to fix that if needed. For userland we do this here:

https://github.com/bsdjhb/gdb/blob/master/gdb/fbsd-tdep.c#L1727

Thanks for the info. So far gdb(4) does not perform any kind of FreeBSD-to-GDB signal mapping, so it may be easiest to move to an "always return SIGTRAP" policy and eliminate a bunch of code. I will give it some thought.

On a second look, I found that gdb_cpu_signal() only returns standard POSIX signals, meaning that at present no mapping is required between FreeBSD and GDB signals. PowerPC is the slight exception to this, which might return a trap vector instead of a signal, and will be addressed.

So, this change should be sufficient to ensure we always transmit something sensible to the gdb client.