Re: [edk2] [PATCH 4/6] ArmVirtPkg: use small code model for all UEFI_APPLICATION modules

[Laszlo Ersek]

On 01/04/16 21:49, Ard Biesheuvel wrote:
> On 4 January 2016 at 19:27, Laszlo Ersek  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 
>>> ---
>>>  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 ,
>> 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 

Re: [edk2] [PATCH 4/6] ArmVirtPkg: use small code model for all UEFI_APPLICATION modules

[Ard Biesheuvel]

On 4 January 2016 at 19:27, Laszlo Ersek  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 
>> ---
>>  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 ,
> 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 

Re: [edk2] [PATCH 4/6] ArmVirtPkg: use small code model for all UEFI_APPLICATION modules

[Laszlo Ersek]

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 
> ---
>  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.

In ,
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)?

Would ArmVirtPkg build (with all supported toolchains) using the "small"
code model?

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 4/6] ArmVirtPkg: use small code model for all UEFI_APPLICATION modules

[Ard Biesheuvel]

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 
---
 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
-- 
2.5.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel