On Sun, Dec 27, 2015 at 08:02:34PM +0100, Ard Biesheuvel wrote: > On 27 December 2015 at 18:58, Leif Lindholm <[email protected]> wrote: > > On Thu, Dec 24, 2015 at 02:03:16PM +0100, Ard Biesheuvel wrote: > >> The tiny code model for AARCH64 is the most efficient model, since its > >> symbol references are relative via a single 32-bit ADR instruction. This > >> gives us a range of only +/- 1 MB, but this is sufficient for the vast > >> majority of the modules that make up a typical EDK2 firmware. Since the > >> reference is relative, it does not result in a fixup entry in the PE/COFF > >> relocation table. Unlike the small code model, which uses ADRP > >> instructions, > >> the tiny model does not impose section alignment requirements. > >> > >> However, in some cases, (e.g., the full Shell binary built in DEBUG mode) > >> the resulting binary exceeds 1 MB, which may result in build errors if > >> code at one end of the image references a symbol at the other end. > >> > >> Since the tiny and small code models can coexist in a single binary, we > >> can work around this problem by making sure that tiny model .text and > >> .data sections are emitted in close proximity to each other, by reducing > >> the function alignment for tiny model code (which by itself should also be > >> an improvement in terms of code size), and sorting the linker input by > >> alignment. > > > > Hmm... > > Not elegant, but effective. And the best I could come up with ...
Yeah, I'm not really objecting, it just feels a bit more like patchwork than fix. > >> Contributed-under: TianoCore Contribution Agreement 1.0 > >> Signed-off-by: Ard Biesheuvel <[email protected]> > >> --- > >> BaseTools/Conf/tools_def.template | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/BaseTools/Conf/tools_def.template > >> b/BaseTools/Conf/tools_def.template > >> index 0cc85a6f359d..fbf0841fc91f 100644 > >> --- a/BaseTools/Conf/tools_def.template > >> +++ b/BaseTools/Conf/tools_def.template > >> @@ -4437,10 +4437,10 @@ DEFINE GCC49_ASM_FLAGS = > >> DEF(GCC48_ASM_FLAGS) > >> DEFINE GCC49_ARM_ASM_FLAGS = DEF(GCC48_ARM_ASM_FLAGS) > >> DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) > >> DEFINE GCC49_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) > >> -DEFINE GCC49_AARCH64_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) > >> DEF(GCC44_ALL_CC_FLAGS) -mcmodel=tiny DEF(GCC_AARCH64_CC_FLAGS) > >> +DEFINE GCC49_AARCH64_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) > >> DEF(GCC44_ALL_CC_FLAGS) -mcmodel=tiny -falign-functions=4 > >> DEF(GCC_AARCH64_CC_FLAGS) > > > > My GCC manpage claims that > > "-Os disables the following optimization flags: -falign-functions ..." > > and -Os is set in GCC_ALL_CC_FLAGS, and as far as I can see not > > overridden for AARCH64, except for DEBUG builds. > > > > OK, that means we will need to build the RELEASE Shell components with > -O2 rather than -Os if we ever hit the same issue for RELEASE builds. > Since those modules are not the ones where we are likely to care > deeply about code size, this is not a showstopper I think Could we move the -falign-functions=4 to DEBUG_GCCnn_AARCH64_CC_FLAGS instead then, next to the -O0? I'd prefer keeeping dead parameters off the command line where possible. Of course, could make sense to change the DEBUG_GCCnn_AARCH64_CC_FLAGS to include a common DEBUG_GCC_AARCH64_CC_FLAGS variable where these are set instead. > >> DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS) > >> DEFINE GCC49_ARM_DLINK2_FLAGS = DEF(GCC48_ARM_DLINK2_FLAGS) > >> -DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GCC48_AARCH64_DLINK_FLAGS) > >> +DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GCC48_AARCH64_DLINK_FLAGS) > >> --sort-section=alignment > > > > No objection to this one. > > > >> DEFINE GCC49_AARCH64_DLINK2_FLAGS = DEF(GCC48_AARCH64_DLINK2_FLAGS) > >> DEFINE GCC49_ARM_ASLDLINK_FLAGS = DEF(GCC48_ARM_ASLDLINK_FLAGS) > >> DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) > >> -- > >> 2.5.0 > >> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
