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.
