gdb(4): fix x86 signal reporting

[mhorne]

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.

[kib]

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.

[jhb]

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

[mhorne]

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.

[mhorne]

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.