I certainly have no objection in principle. I doubt that any x86 userland
apps expect certain si_code values for SIGTRAP now, since the existing
values are not of any real use. (Signal handlers get the thread.trap_no and
thread.error_code values from hardware to guess from, and debuggers via
ptrace get the hardware %db6 value to guess from.) I do have a few comments.
If you're doing it, I think you should do the do_int3 case too,
so every machine-generated SIGTRAP has a meaningful si_code value.
I'm inclined to consolidate the si_code logic there, and just
pass it the hardware bits or let it get them from the thread_struct
(trap_nr, error_code, debugreg6).