On 4 January 2016 at 19:27, Laszlo Ersek <ler...@redhat.com> wrote: > On 12/24/15 14:03, Ard Biesheuvel wrote: >> Unfortunately, compiling the DEBUG shell using the small code model is >> not sufficient in all cases to get a successful build when the toolchain >> defaults to the tiny code model. The reason is that not only the Shell binary >> itself should be built using the small code model, all Shell component >> libraries that are linked into the Shell binary via NULL library class >> resolution should use the small code model as well. >> >> So override the code model and function alignment for DEBUG builds of >> UEFI_APPLICATION modules when using GCC 4.9 (which is the only toolchain >> that uses the tiny model). This should affect all Shell component libraries >> in addition to the Shell core binary. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> >> --- >> ArmVirtPkg/ArmVirt.dsc.inc | 21 ++++++++++++++++++++ >> 1 file changed, 21 insertions(+) >> >> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc >> index 49e4264ee8a4..fbd710cb870d 100644 >> --- a/ArmVirtPkg/ArmVirt.dsc.inc >> +++ b/ArmVirtPkg/ArmVirt.dsc.inc >> @@ -406,3 +406,24 @@ [Components.common] >> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE >> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000 >> } >> + >> +[BuildOptions.AARCH64.EDKII.UEFI_APPLICATION] >> + # >> + # The bulk of the Shell functionality is implemented by UEFI_APPLICATION >> + # libraries that are linked into the Shell binary via NULL library class >> + # resolution. Since the Shell built in DEBUG mode exceeds the 1 MB range >> of >> + # the AARCH64 tiny code model which we use by default on GCC 4.9 and >> later, >> + # the .text and .data sections of the remaining base libraries (which are >> + # built using the tiny code model regardless of the model we use for >> + # UEFI_APPLICATION modules) should be kept as close together as possible. >> + # >> + # By reverting to 8 byte function alignment for UEFI_APPLICATION modules >> + # (which is usually the default, but will be lowered to 4 if we are using >> the >> + # tiny code model) and letting the linker sort its input by alignment, we >> can >> + # force all UEFI_APPLICATION small code model .text input sections to >> appear >> + # first in the binary. The remaining base libraries will end up in close >> + # proximity of each other at the end of the image, preventing out of range >> + # problems when relocating their tiny model (+/- 1 MB) symbol references. >> + # >> + DEBUG_GCC49_*_CC_FLAGS = -mcmodel=small -falign-functions=8 >> + DEBUG_GCC49_*_DLINK_FLAGS = -z common-page-size=0x1000 >> > > I don't have technical objections, just that I don't really like the > complexity of this. >
You're right, this is awful. > In <http://thread.gmane.org/gmane.comp.bios.edk2.devel/6213/focus=6249>, > you wrote > >> Well, this is primarily caused by the way the Shell is composed of >> static libraries, and it is unlikely that this should ever affect >> other UEFI_APPLICATION modules as well. And building everything else >> with the large code model because of this seems backwards to me too. > > I think I'd prefer a "one size fits all" code model where we (as > developers) get to keep our sanity, even if it costs a tiny bit more > resources at runtime. Can you please summarize (again?) the benefits of > the tiny model over the small model? > > I can see the ADR / ADRP discussion in patch 3/6, but what does that > difference mean in practice? > > What savings justify the code model proliferation between GCC <= 4.8 > ("large"), CLANG 3.5 ("small"), GCC >= 4.9 ("tiny", except for the DEBUG > Shell, which would be made "small" by the above)? > I failed to cc you for the followup of this series, which no longer changes anything under ArmVirtPkg http://thread.gmane.org/gmane.comp.bios.edk2.devel/6307 There are a couple of reasons for supporting all of these code models: - tiny is preferred for code size, which is a huge deal for bare metal firmware - small is the only Clang supported model that is compatible with PE/COFF conversion (Clang has no tiny model, and its large model folds its absolute symbol references into instruction immediate fields, and PE/COFF has no runtime relocation for that) - large is preferred over small when code size is concerned, but results in lots of relocations (since all symbol references are absolute) - EDK2, being a reference implementation for bare metal ARM platforms in addition to being the upstream for ArmVirtQemu, should support the toolchains and code models its users are likely to use. > Would ArmVirtPkg build (with all supported toolchains) using the "small" > code model? > Yes, it builds fine in small and large. The only problematic one is tiny. Bottom line: I am moving DEBUG_GCC49 to the small model to avoid the build issues this series aims to fix as well. That way, we can drop the overrides in ShellPkg and ArmVirtQemu. Note that I have also proposed a way to pass the -mstrict-align only to modules that require it. (The code size increase caused my applying it to all modules is what broke the DEBUG_GCC49 in the first place) http://thread.gmane.org/gmane.comp.bios.edk2.devel/6333 -- Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
