https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #9 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from Indu Bhagat <indu.bhagat at oracle dot com> ---
> Recently to fix PR ld/33146, commit 939eb467b21de5d18ee703755fb9704a525cfe21
> added some tests to be run with --gsframe. SFrame sections are of type
> SHT_GNU_SFRAME, a new section type added for GNU/Linux. Disabling them from
> Solaris is an option:
>
> --- a/ld/testsuite/ld-plugin/lto.exp
> +++ b/ld/testsuite/ld-plugin/lto.exp
> @@ -52,7 +52,9 @@ if { [check_lto_fat_available] } {
> }
>
> set as_gsframe ""
> -if { [gas_sframe_check] } {
> +if { [gas_sframe_check] \
> + && ([istarget "x86_64-*-linux-gnu"] || [istarget "aarch64-*-linux-gnu"]
> \
> + || [istarget "s390x-*-linux-gnu"]) } {
> set as_gsframe "-Wa,--gsframe"
> }
true, but why would this be necessary, especially when gcc is using both
gas and gld? This combo should be able to handle them just fine, I'd
think, or is there something OS-specific about them? When using the
native Solaris linker, that might (or might not) be another issue, can't
tell in how far the linker needs to know about those sections.
> But that brings up the larger question of why does gas entertain --gsframe for
> non GNU/Linux platforms at all. May be it shouldnt. We could add a check in
> the gas backends that support SFrame to check for TARGET_OS string ends with
> "gnu" and not emit SFrame otherwise.. I will send a patch soon
Same question: what's OS-specific about them?
--
You are receiving this mail because:
You are on the CC list for the bug.
