https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #10 from Indu Bhagat <indu.bhagat at oracle dot com> ---
(In reply to Rainer Orth from comment #9)
> > --- 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.
>
To be clear, the current SEGV is because we do a sframe_plt = NULL if
!normal_target in bfd/elfxx-x86.c _bfd_x86_elf_link_setup_gnu_properties. We
could go ahead and fix this by setting sframe_plt in the else block, perhaps
like (based on analogous block for eh_frame):
else
{
if (lazy_plt)
htab->sframe_plt = init_table->sframe_lazy_plt;
else
htab->sframe_plt = NULL;
}
Now, SFrame contents ATM are not OS-specific, although we do use an OS-specific
section type SHT_GNU_SFRAME, and program header type PT_GNU_SFRAME. Is it okay
to generate SFrame sections with this section type and program header type on
Solaris ?
> > 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?
Nothing in the contents so far is OS-specific. The section type is
SHT_GNU_SFRAME. These sections cannot be simply concatenated at link time,
they need to be merged : first blob of data is SFrame header, then comes SFrame
function descriptor entries and then SFrame frame row entries. With the above
fix, ld should just be able to link them alright (and generate SFrame for .plt
sections) on Solaris too...
--
You are receiving this mail because:
You are on the CC list for the bug.
