This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libiberty patch] pex-unix error behaviour

On 08/21/2018 12:37 PM, Ian Lance Taylor wrote:
On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell <> wrote:

1) If we know we're using vfork, we can tell the parent directly via the
current stack frame and suitable use of volatiles.

I'm pretty reluctant to rely on this special behavior of vfork.  A
system could plausibly #define vfork fork and almost all programs

if '#define vfork fork' is in effect, we already consider it not vfork:

#ifdef vfork /* Autoconf may define this to fork for us. */
# define VFORK_STRING "fork"
# define VFORK_STRING "vfork"

The patch continues to use that distinction. As I mentioned, my manual testing (by adding such a #define), behaved as expected -- the existing behaviour.

would continue to work, but not this one.  I think we would need a
really compelling advantage to start doing handling vfork specially.
But, since errors in this code are essentially non-existent, I don't
see a compelling advantage here.  Is there some larger scheme this is
in aid of?

On the modules branch the user can provide a mapper program, which we then communicate with. So we're now execing something user-controlled, not part of our configuration.

The error behaviour if that program fails to be exec'd is confusing -- there's an error about the exec failing but it's not attached to location information and the like, then there's a much more obvious error about communication failing. I found it confusing the first time I tripped over it (and I was writing that bit of the compiler :)

Nathan Sidwell

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]