This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [PATCH] [BZ #18433] Check file access/existence before forking.


On Sat, Sep 19, 2015 at 2:39 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Rich Felker <dalias@libc.org> writes:
>
>> Yes, I suppose that's a good way to model it. But the returns_twice
>> attribute does not specify under what conditions the function returns
>> again, so unless gcc has vfork-specific knowledge attached to the
>> specific name, I suppose it must just assume everything stays live.
>
> GCC doesn't treat vfork any different from setjmp, or any other function
> marked returns_twice, see calls.c:special_function_p.

special_function_p just defines the set of functions assumed to have
this behavior (setjmp, setjmp_syscall, sigsetjmp, savectx, qsetjmp,
vfork, and getcontext); to find out what the compiler *does* with that
knowledge you have to grep for ECF_RETURNS_TWICE.

As best I can tell, the direct effects of a callsite being marked
ECF_RETURNS_TWICE seem to be that it is not eligible for various
optimizations (e.g. tail call) and, much more importantly, the
control-flow graph for the containing function is annotated with an
"abnormal edge" from *every other callsite which is not known to have
no side effects* to that callsite.

I'm not sure exactly what "abnormal edge" means to GCC, but I think
this should be conservatively correct, whether or not such a function
actually does return twice.

zw


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