Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: DJ Delorie <dj@redhat.com>
Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
Subject: Re: [RFA] save/restore environ in libiberty pex_unix_exec_child
Date: Mon, 07 Dec 2009 20:25:00 -0000	[thread overview]
Message-ID: <e394668d0912071225p4cfc42d8pf7036701d0b81bf3@mail.gmail.com> (raw)
In-Reply-To: <200912072009.nB7K9moj000406@greed.delorie.com>

On Mon, Dec 7, 2009 at 12:09 PM, DJ Delorie <dj@redhat.com> wrote:
>
> If the child assignment truly clobbers the parent, won't the parent's
> assignment clobber the child?
>
> If it's portable enough, using exevpe/execve instead of execvp/execv
> would be preferred.

The context is a child running under vfork.  While the linux man page
says one cannot assume, for example, that the parent is blocked until
the child execs/exits, it would be odd if in implementations where the
parent is not blocked that assignments in the parent clobbered the
child.  s/odd/broken/ even. :-)

[from man vfork]
CONFORMING TO
       4.3BSD,  POSIX.1-2001.  The requirements put on vfork() by the
standards are weaker than those put on fork(2), so an implementation
where the two are
       synonymous is compliant.  In particular, the programmer cannot
rely on the parent remaining blocked until a call of execve(2) or
_exit(2) and  cannot
       rely on any specific behavior with respect to shared memory.

I don't disagree re. execve, *if* it's portable enough.  I wasn't
prepared to investigate the full gamut of portability issues for this.
 Some thought may have gone into what's there now (maybe, maybe not,
but I err'd on the side of being cautious).  My patch seems like a
straightforward fix to what's there now.


  reply	other threads:[~2009-12-07 20:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07 17:26 Doug Evans
2009-12-07 20:10 ` DJ Delorie
2009-12-07 20:25   ` Doug Evans [this message]
2009-12-07 20:55     ` DJ Delorie
2009-12-07 21:37       ` Doug Evans
     [not found] ` <200912072009.nB7K9moj000406__858.220636337315$1260216617$gmane$org@greed.delorie.com>
2009-12-07 20:28   ` Tom Tromey

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=e394668d0912071225p4cfc42d8pf7036701d0b81bf3@mail.gmail.com \
    --to=dje@google.com \
    --cc=dj@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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