[libiberty] pex-unix error behaviour

This is the second patch for pex-unix's child spawning.  Right now, if 
we manage to (v)fork, but the execvp fails, we use write to emit an 
error and then _exit.  The parent discovers the child failed when trying 
to communicate or wait for it.  This can be improved in 2 ways.

1) If we know we're using vfork, we can tell the parent directly via the 
current stack frame and suitable use of volatiles.  The parent blocks 
until the child exits (via _exit or successful execvp).  We can then 
look where the child will have written error information and use that. 
The error looks like:

class-1_a.C:3:15: error: failed execvp of mapper '|nope': No such file 
or directory
3 | export module One;
   |               ^~~
(this is coming from the module code)

2) Otherwise, if we're using fork we keep the old behaviour, but we can 
use stdio rather than write directly.
The error looks like:

cc1plus: error trying to exec 'nope': execvp: No such file or directory
class-1_a.C:3:15: error: unexpected close from mapper '|nope'
3 | export module One;
   |               ^~~
class-1_a.C:3:15: error: mapper '|nope' exit status 255

(the cc1plus error is that coming from pex-unix, the later diagnostic is 
when the parent discovers something's wrong trying to communicate).

I had to change the indentation more than expected, to avoid a maybe 
clobbered warning about the (non-volatile) bad_fn.  If you'd like that 
indentation altered separately, let me know.

booted and tested on x86_64-linux.  I manually tested both the fork and 
vfork configurations with a non-existent child executable as shown above.

ok?

nathan

On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell <nathan@acm.org> 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
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?

Ian

On 08/21/2018 12:37 PM, Ian Lance Taylor wrote:
> On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell <nathan@acm.org> 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.

> 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

On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <nathan@acm.org> wrote:
> On 08/21/2018 12:37 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell <nathan@acm.org> 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?

Ian

On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
> On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <nathan@acm.org> wrote:

> OK, but what about a system that does
> 
> int vfork() { return fork(); }
> 
> ?

Isn't such a system just buggy? Hm, apparently not.  Because of the 
requirement the user just calls 'exec(), _exit ()' a conformant program 
cannot tell whether it's fork-like or not.  However we're already 
violating that constraint by dinking environ and calling close & write 
[in ways that are ok regardless of a fork-like attribute].  I see the 
man page says '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 the child either terminates or calls 
execve(2), and cannot rely on any specific behavior with respect to 
shared memory.'

pants.  I suppose we could add an autoconf test to probe whether the 
child and parent are serialized or not.  that may or may not be simpler 
than ...

>> 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?

Maybe, ideas?  (but this seemed the simplest way for me to get it to do 
what I wanted :)

nathan

On Tue, Aug 21, 2018 at 12:46 PM, Nathan Sidwell <nathan@acm.org> wrote:
> On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <nathan@acm.org> wrote:
>
>
>> OK, but what about a system that does
>>
>> int vfork() { return fork(); }
>>
>> ?
>
>
> Isn't such a system just buggy? Hm, apparently not.  Because of the
> requirement the user just calls 'exec(), _exit ()' a conformant program
> cannot tell whether it's fork-like or not.  However we're already violating
> that constraint by dinking environ and calling close & write [in ways that
> are ok regardless of a fork-like attribute].  I see the man page says '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
> the child either terminates or calls execve(2), and cannot rely on any
> specific behavior with respect to shared memory.'
>
> pants.  I suppose we could add an autoconf test to probe whether the child
> and parent are serialized or not.  that may or may not be simpler than ...
>
>>> 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?
>
>
> Maybe, ideas?  (but this seemed the simplest way for me to get it to do what
> I wanted :)

The usual technique for better error handling is to open a pipe before
the fork, mark the pipe as close-on-exec, and have the child write
error information to the pipe.  The parent can then read from the
pipe; if it reads nothing, then the pipe was closed by the exec and
all is well.

Ian