On Fri, Mar 7, 2025 at 11:07 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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.
I agree. Referring to these options as incompatible implies that this just wont work and there are correctness issues. They are incompatible in the sense that it depends on link order whether the ultimate elf module can be constructed or not and whether the final ELF module whether a shared object or an executable ( statically or dynamically linked) fits in the space requirements of the memory model. If it doesn't yes it's an unpleasant user experience but it's fundamentally not incompatible. Anecdotally I have very recently heard of a couple of cases where folks use linker scripts to place such sections to make this work : today IIUC they could write a linker script and use that at link time to get an application together. Some users might prefer that others might prefer other tricks and it's difficult to have a one size fits all solution. Are we leaving users without an option if the compiler won't even allow -mcmodel=large + static linking. ? I see a few users who have large applications that they are bringing on to AArch64 linux -mcmodel=large is probably the only escape hook currently until some of this is fixed in the tools and that catches up via versions in the distros. Cheers Ramana > > 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
