This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: close-on-exec internal file descriptors
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 1 May 2013 18:47:22 +0400
- Subject: Re: RFC: close-on-exec internal file descriptors
- References: <874njjs1aa dot fsf at fleche dot redhat dot com> <m2vcbzui0o dot fsf at igel dot home> <87fw32p00e dot fsf at fleche dot redhat dot com> <874niy6y35 dot fsf at fleche dot redhat dot com> <87d2tmsey0 dot fsf at fleche dot redhat dot com>
Hi Tom,
> Tom> 2013-01-03 Tom Tromey <tromey@redhat.com>
>
> Tom> PR gdb/7912:
> Tom> * Makefile.in (SFILES): Add filestuff.c
> Tom> (COMMON_OBS): Add filestuff.o.
> Tom> (filestuff.o): New target.
> [...]
Unfortunately, this is causing problems on Darwin and HP/UX,
because both platforms use pipes to synchronize parent and
child during the fork/exec. See for instance darwin-nat.c:
/* The child must synchronize with gdb: gdb must set the exception port
before the child call PTRACE_SIGEXC. We use a pipe to achieve this.
FIXME: is there a lighter way ? */
static int ptrace_fds[2];
Same mechanism, and therefore problem, with HP/UX targets:
/* File descriptors for pipes used as semaphores during initial
startup of an inferior. */
static int inf_ttrace_pfd1[2];
static int inf_ttrace_pfd2[2];
In terms of behavior, GDB either hangs during process creation, or
reports a fatal failure during one of the system calls.
I don't think there is a way of opening a FD with the intention
of protecting them from the close-at-exec, is there? So, the solution
would seem to add an interface to setup the protection, as well
as a function to remove that protection (necessary when we close
the fd).
What do you think?
--
Joel