From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFC] undefine SIGHUP if function kill not available...
Date: Wed, 07 Jan 2009 11:58:00 -0000 [thread overview]
Message-ID: <20090107115832.GF1751@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
I have just seen Mark's comments (thank you!) about this patch, so I just
downgraded this request to a request for comments.
Here is the problem:
In event-top.c, some code that is conditional on SIGHUP being defined
also uses kill(). On x86_64-windows, the MinGW signal.h now defines
SIGHUP, but kill is still not available. So the approach I took for
now was to pretend that SIGHUP is not defined if kill is not available.
This is clearly a hack, hence the comment I added.
Mark's comments were:
> > AC_CHECK_FUNCS([canonicalize_file_name realpath getrusage getuid \
> > - getgid poll pread64 sbrk setpgid setpgrp setsid \
> > + getgid kill poll pread64 sbrk setpgid setpgrp setsid \
> > sigaction sigprocmask sigsetmask socketpair syscall \
> > ttrace wborder setlocale])
>
> Why the hell do we need to add a check for a function defined by ISO C90?
>
> > +#if defined (SIGHUP) && !defined (HAVE_KILL)
> > +/* On x86_64-windows, MingW's signal.h defines SIGHUP but does not
> > + provide "kill". However, the code that uses SIGHUP below also
> > + uses kill. So, if kill is not available, pretend SIGHUP isn't
> > + either. */
> > +#undef SIGHUP
> > +#endif
>
> This must be a bug in MingW. Please tell the MingW people that in
> 2008 they manage to ship an environment that doesn't even implement
> ISO C90 correctly. If they fix it (or have already fixed it) is it
> really necessary to add this ugly workaround?
Just to make sure I understand, my understanding is the fact that
"kill" is not available, right? Not knowing Windows all that well,
I wonder how much sense a "kill" routine would make.
That being said, I agree that, if MinGW has already fixed the problem,
it's reasonable to require a recent version of MinGW. I will double-check
for sure. But in the event that this is not the case, I think it's
reasonable to add the workaround. I should probably add a FIXME and a
date, to show that this should really be a temporary measure. Or maybe
there's a better way?
2009-01-07 Joel Brobecker <brobecker@adacore.com>
* configure.ac: Add kill to the list of functions to check.
* configure, config.in: Regenerate.
* event-top.c: Undefine SIGHUP if kill is not available.
Tested on x86-windows and x86-linux.
--
Joel
[-- Attachment #2: kill.diff --]
[-- Type: text/plain, Size: 1126 bytes --]
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 4e0cf7d..e970234 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -774,7 +774,7 @@ AC_FUNC_ALLOCA
AC_FUNC_MMAP
AC_FUNC_VFORK
AC_CHECK_FUNCS([canonicalize_file_name realpath getrusage getuid \
- getgid poll pread64 sbrk setpgid setpgrp setsid \
+ getgid kill poll pread64 sbrk setpgid setpgrp setsid \
sigaction sigprocmask sigsetmask socketpair syscall \
ttrace wborder setlocale])
diff --git a/gdb/event-top.c b/gdb/event-top.c
index 5483608..dd223e1 100644
--- a/gdb/event-top.c
+++ b/gdb/event-top.c
@@ -50,6 +50,14 @@ static void change_line_handler (void);
static void change_annotation_level (void);
static void command_handler (char *command);
+#if defined (SIGHUP) && !defined (HAVE_KILL)
+/* On x86_64-windows, MingW's signal.h defines SIGHUP but does not
+ provide "kill". However, the code that uses SIGHUP below also
+ uses kill. So, if kill is not available, pretend SIGHUP isn't
+ either. */
+#undef SIGHUP
+#endif
+
/* Signal handlers. */
#ifdef SIGQUIT
static void handle_sigquit (int sig);
next reply other threads:[~2009-01-07 11:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 11:58 Joel Brobecker [this message]
2009-01-08 13:51 ` Joel Brobecker
2009-01-08 15:30 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090107115832.GF1751@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox