https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #50 from ard.biesheuvel at linaro dot org --- (In reply to Ramana Radhakrishnan from comment #49) > (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. > AIUI the small model allows images up to 4 GB (since that is the range of adrp+lo12), and the large model allows any size, by emitting cross section references as literals containing absolute addresses (rather than movz/movk sequences). This relies on the literals themselves being in range, which is usually the case, of course, if they are emitted into the same section, modulo the uses cases that caused this bug in the first place. (BTW my GCC man page erroneously lists the tiny model as having a 1 GB range but this should obviously be 1 MB) So by enabling this feature by default, you are now imposing a 4 GB image limit on the large model as well, since the literals are moved to a different section (which, given our choice for the large model, is not guaranteed to be within 4 GB in the final image), and referenced via instructions that only have a 4 GB range. > 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. I am arguing that enabling this feature essentially breaks the large model, so it should not be enabled by default, and perhaps be made mutually exclusive.
