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 Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <> wrote:
> 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"
> #else
> # define VFORK_STRING "vfork"
> #endif
> The patch continues to use that distinction.  As I mentioned, my manual
> testing (by adding such a #define), behaved as expected -- the existing
> behaviour.

OK, but what about a system that does

int vfork() { return fork(); }


I'm certainly willing to believe that your patch works reliably on
GNU/Linux, but this code has to be extremely portable.

>> 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 :)

Is there any reason we couldn't fix that without relying on the odd
behavior of vfork?


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