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: [RFC] Prevent tailcall optimizations of libdl functions


On 25/01/17 15:43, Florian Weimer wrote:
> On 01/25/2017 04:41 PM, Szabolcs Nagy wrote:
>> On 25/01/17 15:40, Florian Weimer wrote:
>>> On 01/25/2017 04:38 PM, Szabolcs Nagy wrote:
>>>> On 25/01/17 15:32, Yuri Gribov wrote:
>>>>> FWIW it sounds like GCC attribute would be the most natural solution
>>>>> (and probably also useful in other contexts). I'll try to cook a patch
>>>>> for GCC if there are no objections.
>>>>
>>>> note that even if dlsym is marked notailcall, with
>>>>
>>>> p = dlsym;
>>>> ...
>>>> return p();
>>>>
>>>> if the type of p does not carry the attributes of
>>>> dlsym then this can be a tailcall.
>>>
>>> Yes, but dlsym would still see the address of the function containing the dlsym call, which is what we need to
>>> determine the relevant object.
>>
>> how?
> 
> At worst, the return address points to the code which jumps to the address p.  This code is still in the object
> which calls dlsym.
> 

i don't immediately see why.

i'd assume if we want f(RTLD_NEXT, sym) work
for a function pointer f pointing to dlsym
then it would need to prevent tco just like
dlsym to have a return address in the right dso.

(e.g. g() in dso1 calls h() in dso2 which
calls f that is dlsym, whether h tailcalls
f or not seem to matter)


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