On 2016-07-18 05:09:14, Ard Biesheuvel wrote:
> GCC in LTO mode interoperates poorly with non-standard libraries that
> provide implementations of compiler intrinsics such as memcpy/memset
> or the stack protector entry points. Such libraries need to be built
> in non-LTO mode, and then referenced explicitly on the linker command
> line using a -plugin-opt=-pass-through=-lxxx linker option.
> 
> However, if these intrinsics are also referenced directly, the LTO
> version of the code will be pulled in, and will happily satisfy all
> other references to the same symbol.
> 
> So add a pair of glue libraries, for ARM and AARCH64, that reference
> the known intrinsics. Since the binaries live under ArmPkg directly,
> we can reference them in tools_def.txt. Under LD garbage collection,
> the object itself will be pruned, and so will the intrinsics that end
> up unused by the module.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPkg/GccLto/liblto-aarch64.a | Bin 0 -> 1016 bytes
>  ArmPkg/GccLto/liblto-aarch64.s |  15 ++++++
>  ArmPkg/GccLto/liblto-arm.a     | Bin 0 -> 2096 bytes
>  ArmPkg/GccLto/liblto-arm.s     |  49 ++++++++++++++++++++
>  4 files changed, 64 insertions(+)
> 
> diff --git a/ArmPkg/GccLto/liblto-aarch64.a b/ArmPkg/GccLto/liblto-aarch64.a
> new file mode 100644
> index 
> 0000000000000000000000000000000000000000..2ab00238f0dad882abf08a1fb9623c9cdea9f17b
> GIT binary patch
> literal 1016
> zcmbu7&rZTX5XPqz6oLo!M8btcV>pmaJb3R#Pab@Ovb0qUG$GwJk&}<*)yMErJh~su
> zhGA(FBh#ci^V@G{X8(NLKR&dgh`dGgNxR5Xq8|a14Nj;_ot@whUR;}*D0W|+#ne8)
> z+crcqtbp?TKuy$d;Fk^js)5sWPGwPMt2G8wSV~i4b+$;e`67MRugg8~@}{d?w$pJf
> z%hU2Z13wYMF8ko8f}aWQH5;VNy0m&m%Ghc<&b?O^ORa42Zb{|ZYEm;}M9QPwkz0*h
> zki8>ef}gYSE})e*bOFvFk<j^57EYNXKak(^fcXvc@Z~)5d^m*lCr*Hz|6PAkvlcbK
> oxX>*EVPSp5Eivz1-~TrQyaBwMaQ{8W!rrlD%!Td{2n*}~0;u;a`v3p{
> 
> literal 0
> HcmV?d00001
> 
> diff --git a/ArmPkg/GccLto/liblto-aarch64.s b/ArmPkg/GccLto/liblto-aarch64.s
> new file mode 100644
> index 000000000000..1215858edd43
> --- /dev/null
> +++ b/ArmPkg/GccLto/liblto-aarch64.s
> @@ -0,0 +1,15 @@
> +//

Can you add the standard license header on these files?

-Jordan

> +// GCC in LTO mode interoperates poorly with non-standard libraries that
> +// provide implementations of compiler intrinsics such as memcpy/memset
> +// or the stack protector entry points.
> +//
> +// By referencing these functions from a non-LTO object that can be passed
> +// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
> +// intrinsics are included in the link in a way that allows them to be
> +// pruned again if no other references to them exist.
> +//
> +
> +       .long   memcpy - .
> +       .long   memset - .
> +       .long   __stack_chk_fail - .
> +       .long   __stack_chk_guard - .
> diff --git a/ArmPkg/GccLto/liblto-arm.a b/ArmPkg/GccLto/liblto-arm.a
> new file mode 100644
> index 
> 0000000000000000000000000000000000000000..d811c09573a35ea87a8002ecf01be18e1c6e7fd3
> GIT binary patch
> literal 2096
> zcmd6o%WKq76vn?XQ*C|Js#WW|YOD1@u(oJH7cHm=wjd(Xg%C3{sS}#eGD-SEunQLz
> zT?o1mx)E36&V>ti;!4n^e}Mi6u3h<^n@J{fT<Fp}Ouq9w_nvbfNlqSKoxD~mm5{X(
> zhR`D5^G4ItF=}K8T}U0-`2R^Kc5yYX=T>}_x@dNmx{6!*W2si#P63O*VzW?IBihqh
> z=)ig*pojKb#bw326`xc*toV}R>x!op&nRA0ysG%I;^&HAD}JZ=gW^w$zbO8u_=n=3
> zihn6C7jA)^cemm`#e<4%#TOM%D88Zij$&7Fpm;^`6UFO_-zdgF4UQAVZgtkF)@Pj=
> z*ALnp_Y=1vL)@s|sQDwQ6*Mh*7aYIlFNiybaLxo6PTG16rQHlllhBAv-k>#u2@Sol
> zI=`G}CPrQiN;tRR(ak(*AdNItn6xb{AamTrttlr6972!~lYGJ?&mg`uh4`8leFjDu
> zR1H=l|GXG+(@3h}e9gF`ML(|A$Jm)#Ny{9*kb6fYIz6K#U~GZXiE;<`AQQJZh#Ex*
> zvPafpsg(EM+QeEU%F9+!7AJXjt<6BM=oX+)l${4fw*md4-N1n8cCac_8FW^32XIbw
> zCm?m%V%-}PWwOhnEHdMwdw?sVdjY8%7AKh$-3Qzh-4EOrJpf1@u{il%(L=yJ(ZfJZ
> z^axNF?FRzUqrklAF(4K_4lIdsu@6KCfmP8Hz#~x>xiwL4;;HB<;F;)Y;DzWJUhHT&
> zjNJ+~ZlqeztcDlZv9}b%uDP)byAnmP`PA5M95?(*5_=I7{9EHzOij<eVx#1jh0yHv
> z<B{-Nm!6|^Pj~Rl*~wdJ;>*-d{<&4d*_Y!hx!AINvPBvHw{hmarpIg2NWNZUrI#!p
> wAAvlV^sI41<6<;hHcoUy=A?e-|05l;7C8giM-Tt9*KBPx@rv+1OG3`f-+dwCzyJUM
> 
> literal 0
> HcmV?d00001
> 
> diff --git a/ArmPkg/GccLto/liblto-arm.s b/ArmPkg/GccLto/liblto-arm.s
> new file mode 100644
> index 000000000000..48c682f92e08
> --- /dev/null
> +++ b/ArmPkg/GccLto/liblto-arm.s
> @@ -0,0 +1,49 @@
> +//
> +// GCC in LTO mode interoperates poorly with non-standard libraries that
> +// provide implementations of compiler intrinsics such as memcpy/memset
> +// or the stack protector entry points.
> +//
> +// By referencing these functions from a non-LTO object that can be passed
> +// to the linker via the -plugin-opt=-pass-through=-lxxx options, the
> +// intrinsics are included in the link in a way that allows them to be
> +// pruned again if no other references to them exist.
> +//
> +
> +       .long   memcpy - .
> +       .long   memset - .
> +       .long   __stack_chk_fail - .
> +       .long   __stack_chk_guard - .
> +       .long __ashrdi3 - .
> +       .long __ashldi3 - .
> +       .long __aeabi_idiv - .
> +       .long __aeabi_idivmod - .
> +       .long __aeabi_uidiv - .
> +       .long __aeabi_uidivmod - .
> +       .long __divdi3 - .
> +       .long __divsi3 - .
> +       .long __lshrdi3 - .
> +       .long __aeabi_memcpy - .
> +       .long __aeabi_memset - .
> +       .long memmove - .
> +       .long __modsi3 - .
> +       .long __moddi3 - .
> +       .long __muldi3 - .
> +       .long __aeabi_lmul - .
> +       .long __ARM_ll_mullu - .
> +       .long __udivsi3 - .
> +       .long __umodsi3 - .
> +       .long __udivdi3 - .
> +       .long __umoddi3 - .
> +       .long __udivmoddi4 - .
> +       .long __clzsi2 - .
> +       .long __ctzsi2 - .
> +       .long __ucmpdi2 - .
> +       .long __switch8 - .
> +       .long __switchu8 - .
> +       .long __switch16 - .
> +       .long __switch32 - .
> +       .long __aeabi_ulcmp - .
> +       .long __aeabi_uldivmod - .
> +       .long __aeabi_ldivmod - .
> +       .long __aeabi_llsr - .
> +       .long __aeabi_llsl - .
> -- 
> 2.7.4
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to