Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 22/06/2021 13:17, John Mellor-Crummey wrote:
> Florian,
> 
> 
>> On Jun 22, 2021, at 10:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * John Mellor-Crummey:
>>
>>>> On Jun 22, 2021, at 3:15 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>> You can already see this non-interceptable thread creation behavior
>>>> today (in glibc 2.33 and earlier) with thrd_create, which does not
>>>> result in a pthread_create call, either, despite creating a new thread
>>>> as if by pthread_create.
>>>
>>> Having a non-interposable thrd_create is a problem for us too, though 
>>> we haven’t yet seen it in practice in HPC applications (or maybe it happened
>>> and we were just unaware!).
>>
>> I meant that thrd_create needs to be intercepted separately.  This will
>> still work.
> 
> Got it.
> 
> Would you recommend intercepting clone instead of trying
> to intercept pthread_create and thrd_create?
> 
> That should avoid trouble interposing pthread_create.

Interposing 'clone' falls in the same category, the syscall is issued directly
within de clode. 

Currently, you need to interpose both pthread_create and thrd_create.  Florian
has suggested we allow pthread_create to be interposable (meaning glibc will
issue a plt call on each usage). 

We can do it for clone instead, it would have the advantage to hide the multiple
architecture different kernel ABIs.


> 
>>
>>>> Going back to trheading, I find it a bit curious that you intercept
>>>> pthread_create, but not pthread_join.  How do you detect thread exit?  I
>>>> assume you are interested in that event, too.  Merely wrapping the
>>>> thread start routine is insufficient because there are other ways for a
>>>> thread to exit besides returning from the start routine and calling
>>>> pthread_exit (e.g., thread cancellation and unwinding).
>>>
>>> We use pthread_cleanup_push to add a routine that will be called when a thread
>>> exits.
>>
>> Okay, that should work, although some application-supplied TLS
>> destructors will run later than that.
> 
> For our tools, we need to shut down profiling when a thread is finishing. That
> can and should be done before the thread really gets torn down. We have
> learned the hard way that we need to turn off profiling before TLS destruction starts. 
> 
> --
> John Mellor-Crummey		Professor
> Dept of Computer Science	Rice University
> email: johnmc@rice.edu		phone: 713-348-5179
>