Re: Signals on Mingw
On Mon, 23 Nov 2020 at 17:08, Reuben Thomas wrote: > 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! > Yes, looks like the example code is outdated, and I should be using include/gdb/signals.h rather than native signal.h. Thanks for raising this question, Eli! This means in any case that I don't have a use for these signal numbers on Windows. -- https://rrt.sc3d.org
Re: Signals on Mingw
On Mon, 23 Nov 2020 at 16:47, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Mon, 23 Nov 2020 16:38:22 + > > Cc: Bruno Haible , bug-gnulib > > > > 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
Re: Signals on Mingw
> From: Reuben Thomas > Date: Mon, 23 Nov 2020 16:38:22 + > Cc: Bruno Haible , bug-gnulib > > 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? But why is it useful to report signals when none were actually delivered to the program? And how do you make sure the numbers you report will be identical to what GDB itself uses?
Re: Signals on Mingw
On Mon, 23 Nov 2020 at 16:09, Eli Zaretskii wrote: > > 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. -- https://rrt.sc3d.org
Re: Signals on Mingw
> From: Reuben Thomas > Date: Sun, 22 Nov 2020 23:46:37 + > Cc: bug-gnulib > >- Is it useful to have these signal names defined at all? If they can never > occur on native Windows, it does not necessarily make sense to define > them. > > If I wanted native (non-POSIX) functionality, I would not have used the > signal-h module. > > However, it seems _POSIX, when it was used in MSVC, may refer to Windows's > old POSIX subsystem: > https://sourceforge.net/p/mingw-w64/mailman/message/33014416/ > > Also consider the workarounds that Gnulib already does, in > doc/posix-headers/signal.texi . > > I'm already using this, of course! It defines SIGPIPE (but not other missing > signals). > > signal.texi claims that sigset_t will be defined on Windows, but it does this > just by #including , > which does not define sigset_t unless _POSIX is defined. > > The only mention I can find of _POSIX in gnulib is in > doc/posix-functions/getlogin.texi, which mentions that > getlogin is only defined on mingw if _POSIX is defined (as I noted above). > The solution of the getlogin module > is to use the unistd module to declare getlogin, if I understand correctly. 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.
Re: Signals on Mingw
On Sun, 22 Nov 2020 at 22:47, Bruno Haible wrote: > > Two questions to consider: > > - What other effects would it have to define '_POSIX' ? In which other > places > is this macro being referenced? > It is used to define modes for read/write in fcntl.h (O_RDONLY and friends), getlogin and possibly alarm in io.h, fileno, tempnam and some other functions and constants in stdio.h, rand_r in stdlib.h, sigset_t in sys/types.h, tzset and some related functions in time.h, to define ftruncate and friends in unistd.h with off32_t rather than _off32_t, __USE_MINGW_ANSI_STDIO if not already defined in _mingw.h, and the off_t types without a leading underscore in _mingw_off_t.h. It would be possible to ensure that _POSIX is defined, #include signal.h, then undefine _POSIX if it was not previously defined, and this would avoid switching on POSIX functionality in other headers by accident. - Is it useful to have these signal names defined at all? If they can > never > occur on native Windows, it does not necessarily make sense to define > them. > If I wanted native (non-POSIX) functionality, I would not have used the signal-h module. However, it seems _POSIX, when it was used in MSVC, may refer to Windows's old POSIX subsystem: https://sourceforge.net/p/mingw-w64/mailman/message/33014416/ > Also consider the workarounds that Gnulib already does, in > doc/posix-headers/signal.texi . > I'm already using this, of course! It defines SIGPIPE (but not other missing signals). signal.texi claims that sigset_t will be defined on Windows, but it does this just by #including , which does not define sigset_t unless _POSIX is defined. The only mention I can find of _POSIX in gnulib is in doc/posix-functions/getlogin.texi, which mentions that getlogin is only defined on mingw if _POSIX is defined (as I noted above). The solution of the getlogin module is to use the unistd module to declare getlogin, if I understand correctly. -- https://rrt.sc3d.org
Re: Signals on Mingw
Hi Reuben, > I find that it is necessary to #define _POSIX to get a full set of POSIX > signal names defined in mingw's signal.h. I'm slightly surprised to find > this is not implemented in gnulib: is there a reason? > > If not, it would be straightforward to add > > #ifdef __MINGW32__ > #define _POSIX > #endif > > before the #include of the system signal.h > > # @INCLUDE_NEXT@ @NEXT_SIGNAL_H@ > > in signal.in.h. Two questions to consider: - What other effects would it have to define '_POSIX' ? In which other places is this macro being referenced? - Is it useful to have these signal names defined at all? If they can never occur on native Windows, it does not necessarily make sense to define them. Because then an application could not conditionalize like this: #ifdef SIGFOO ... install signal handler for SIGFOO ... #endif Also consider the workarounds that Gnulib already does, in doc/posix-headers/signal.texi . Bruno
