Re: [PATCH] Compile elf/rtld.c with -fno-tree-loop-distribute-patterns.

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 26/11/2019 11:14, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 25/11/2019 19:28, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> Sigh... The dl_start_final_info struct is roughly 660 bytes (664 on powerpc
>>>> for instance, slight larger on mips). I wonder if we could just create a
>>>> static global on rtld.c to simplify it, since the stack usage won't be
>>>> released anyway.
>>>
>>> I thought the stack is reset by the startup stub?
>>
>> It is and also it seems we are stuck on using stack allocated for
>> bootstrap_map for some architectures. For instance, the
>> powerpc32/fpic always generate a GOT access even for static
>> variables (and some comments on rltd.c about it do not grasp all
>> architecture requirements).
> 
> So should we just apply Sandra's patch?

I don't have a strong preference: either disabling for whole rltd.c (Sandra's
patch), your suggestion to restrict !PI_STATIC_AND_HIDDEN, or to use  
inhibit_loop_to_libcall on _dl_start only. I don't think 
-ftree-loop-distribute-patterns would have a large performance difference.

> 
>>> At one point, we need to rewrite the bootstrap relocation in something
>>> else besides C, but I suppose we can just stick in
>>> -fno-tree-loop-distribute-patterns today.
>>
>> Maybe with some reorganization and refactoring we can simplify the include 
>> hack done with dynamic-link.h while taking care of not generating the
>> required relocations (maybe a compiler flag could help us, at least to
>> warn when such relocation are being emitted?).  But I see your point where
>> we are using C to produce code that is a specific subset of language 
>> standard.
> 
> It's even worse—we try to restrict what we feed to the front end,
> hoping that what comes out of the back end, assembler and linker
> matches our requirements.  That's not how we should do things today.

Yeah, this specific code is fragile and simple changes such as changing
a variable scope can break it. I think we ca at least document the
restrictions and organize better the code (the include in the middle of
the function is really hacky).