[PATCH] [BZ #18433] Check file access/existence before forking.
Richard Henderson
rth@twiddle.net
Mon Sep 21 17:35:00 GMT 2015
On 09/19/2015 08:04 AM, Zack Weinberg wrote:
> 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.
Indeed it does 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.
Abnormal edge, i.e. abnormal flow of control, i.e. longjmp or throw-like.
It's a big hammer that kills quite a lot of data flow analysis, but thankfully
returns_twice functions are rare. And in the situations they are used, there
usually isn't much room for improvement anyway, so why complicate the
correctness issue?
r~
More information about the Libc-alpha
mailing list