[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

--- Comment #49 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to ard.biesheuvel from comment #48)
> (In reply to Richard Earnshaw from comment #47)
> > (In reply to ard.biesheuvel from comment #46)
> > > One issue that this causes, which I did not see mentioned anywhere in the
> > > thread, is that the use of adrp/add and adrp/ldr imposes a 4 KB section
> > > alignment. In EDK2 Tianocore (UEFI reference implementation), we
> > > deliberately use -mcmodel=large to get around this requirement, since code
> > > size is a big deal when executing from NOR flash, and the architecture of
> > > EDK2 (lots and lots of small separately linked binaries) makes
> > > the overhead of 4 KB section alignment prohibitive. (It uses 32 byte section
> > > alignment unless there are objects like a vector table that require more)
> > 
> > Huh?  It imposes a 4k *SEGMENT* alignment.  It doesn't impose a section
> > alignment.
> 
> Indeed, apologies for mixing up the lingo.
> 
> But my point is that -mcmodel=large did not use to impose such a minimum
> alignment, and with this change, it now does. Would it perhaps make sense to
> default enable this feature only for -mcmodel=small (which already uses
> adrp/add anyway)


-mcmodel=large allows for images > 1MiB to be compiled, this change enables
functions > 1MiB in size to exist in images compiled and linked with
-mcmodel=large.

As of now, if you really want to use -mcmodel=large for working around this,
you already have -mpc-relative-literal-loads to allow this.