Wilco Dijkstra <wilco.dijks...@arm.com> writes:
> Hi Richard,
>
>>> Basically the small and large model are fundamentally incompatible. The 
>>> infamous
>>> "dumb linker" approach means it doesn't try to sort sections, so an ADRP 
>>> relocation
>>> will be out of reach if its data is placed after a huge array. Static 
>>> linking with GLIBC or
>>> enabling outline atomics are in fact the same issue.
>>
>> This is probably a daft question, but why does the incompatibility
>> only affect static linking?  Couldn't the same problem affect dynamic
>> executables if the code mixes medium and large code in an unfortunate way?
>
> Any mixing of large and small means you get the lowest common denominator.
> Statically linking with a small model library (like outline atomics or GLIBC) 
> is exactly
> the same as linking in a small object. You effectively end up with max sizes 
> from the
> small model with all the limitations of the large model (no PIC or PIE).
>
> I can't decode the other paragraphs at all - what exactly would you do 
> differently in
> each compilation unit?

That was also what I was trying to say.  In the worst case, the linked
object has to meet the requirements of the lowest common denominator.

And my supposition was that that isn't a property of static vs dynamic.
It applies to both (assuming that dynamic is supported by -mcmodel=large,
despite the current documentation).  If you link medium and large code
together statically, the result (in general) has to be small enough for
the medium model.  The same is true if you link medium and large code
together in a dynamic executable.

So -static isn't intrinsically incompatible with -mcmodel=large.
The documentation seems to be describing a property of the way that
GLIBC is built on GNU/Linux systems, rather than a feature of -static
vs -mcmodel=large per se.

On aarch64-elf, everything is linked statically (unless you go to
heroic lengths to use aarch64-elf on a "full" custom OS).  And that's
fine provided that everything is built with the right model.

Thanks,
Richard

Reply via email to