This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 <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
--
Nathan Sidwell