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] Compile elf/rtld.c with -fno-tree-loop-distribute-patterns.


* 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?

>> 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.


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