Hi Richard,
> 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.
But it is. Dynamic linking supports mixing different code models
On Fri, Mar 7, 2025 at 11:07 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra 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
>
Wilco Dijkstra 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
>
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
>> enabl
Wilco Dijkstra writes:
> Hi Ramana,
>
>> -Generate code for the large code model. This makes no assumptions about
>> -addresses and sizes of sections. Programs can be statically linked only.
>> The
>> +Generate code for the large code model. This allows large .bss and .data
>> +sections, howe
Hi Ramana,
> -Generate code for the large code model. This makes no assumptions about
> -addresses and sizes of sections. Programs can be statically linked only.
> The
> +Generate code for the large code model. This allows large .bss and .data
> +sections, however .text and .rodata must still
On Tue, Mar 4, 2025 at 11:47 PM Wilco Dijkstra wrote:
>
> Hi Kyrill,
>
> > This restriction should be documented in invoke.texi IMO.
> > I also think it would be more user friendly to warn them about the
> > incompatibility if an explicit -moutline-atomics option is passed.
> > It’s okay though t
Hi Kyrill,
> This restriction should be documented in invoke.texi IMO.
> I also think it would be more user friendly to warn them about the
> incompatibility if an explicit -moutline-atomics option is passed.
> It’s okay though to silently turn off the implicit default-on option though.
I've upd
> On 3 Mar 2025, at 19:52, Wilco Dijkstra wrote:
>
>
> Outline atomics is not designed to be used with -mcmodel=large, so disable
> it automatically if the large code model is used.
>
> Passes regress, OK for commit?
>
This restriction should be documented in invoke.texi IMO.
I also think i
