On Mon, 23 Nov 2020 at 16:47, Eli Zaretskii <e...@gnu.org> wrote: > > From: Reuben Thomas <r...@sc3d.org> > > Date: Mon, 23 Nov 2020 16:38:22 +0000 > > Cc: Bruno Haible <br...@clisp.org>, bug-gnulib <bug-gnulib@gnu.org> > > > > Can you elaborate what are you using this module for in the MinGW > > build? AFAIK, Posix signals can never work well enough on Windows to > > care about them. Maybe I'm missing something. > > > > Signal numbers for use in a GDB debugger stub: stubs report > errors/breaks etc to GDB as signal numbers. > > So all you need is signal numbers? >
That's right. But why is it useful to report signals when none were actually > delivered to the program? Because that's how GDB works: it uses signal numbers to represent CPU traps such as page faults and breakpoints. > And how do you make sure the numbers you > report will be identical to what GDB itself uses? > Good question! Looks like the code is relying on the definitions matching. (I used one of the sample debugger stubs, which seems not to have been changed for many years; meanwhile, gdb seems to have introduced its own enumeration. I guess I'll look into this again at some point.) It doesn't seem to matter much anyway, as GDB's remote stub communicator only seems to ever use two concrete values. I guess the rest are just indicative. TBH it's several months since I worked on the code and it was my first time hacking inside GDB! -- https://rrt.sc3d.org
