https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #11 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from Indu Bhagat <indu.bhagat at oracle dot com> ---
> (In reply to Rainer Orth from comment #9)
[...]
>> 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;
> }
That's certainly preferable to a SEGV ;-)
> 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 ?
Sure: there are even a few defined in <sys/elf.h>:
#define SHT_GNU_verdef SHT_SUNW_verdef
#define SHT_GNU_verneed SHT_SUNW_verneed
#define SHT_GNU_versym SHT_SUNW_versym
#define SHT_GNU_ATTRIBUTES 0x6ffffff5 /* Object attributes */
#define SHT_GNU_HASH 0x6ffffff6 /* GNU-style hash table */
#define SHT_GNU_LIBLIST 0x6ffffff7 /* Prelink library list */
Some of them are dealt with by /bin/ld, others merely displayed by
elfdump.
>> > 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...
While /bin/ld doesn't know how to do that (at least ATM), gld does. If
this turns out to be interesting on Solaris, too, /bin/ld might even be
augmented to do that, too.
--
You are receiving this mail because:
You are on the CC list for the bug.
