Differential D27645
gdb(4): fix x86 signal reporting Authored by mhorne on Dec 16 2020, 8:55 PM. Tags None Referenced Files
Details
The existing values correspond to x86 exception vector numbers, but the I have limited this to the subset of trap values for which kdb_trap() is
Diff Detail
Event TimelineComment Actions 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. Comment Actions 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 Comment Actions 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. Comment Actions 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. |