This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

SHT_GNU_ATTRIBUTES advice...


I need some advice in the area of ELF object attributes on sparc.

What used to happen on Sparc is that for new groups of instructions
Sun would add an EF_* bit to the elf header ->e_flags.

But the grouping of available instructions has gotten to the point
that this is not tenable over the long term, so now what they do, on
top of the existing ->e_flags values, is report a set of "hardware
capability" bits in the SHT_SUNW_cap section.

Actually, it's a bit more convoluted than that, there's a section
called SHT_SUNW_capinfo that is like a symbol table.  Entries in
SHT_SUNW_capinfo are symbols that point to entries in the SHT_SUNW_cap
section.  These capabilities symbols are, of course, local.

The kernel and the dynamic linker interrogate this value and compare
it against the auxiliary vector AT_HWCAP hardware capability bits to
make sure the object only uses hardware capabilities the cpu actually
supports.

Unfortunately, the SHT_SUNW_cap value is exactly the same as
SHT_GNU_ATTRIBUTES and the layout is of course quite different.

Initially, I went ahead and started implementing something that uses
SHT_GNU_ATTRIBUTES and which wouldn't be recognized on Solaris.

But then I started to consider that, if possible, I'd really
like to emit ELF objects that would work just as well under
Solaris too.

I'm not so sure how to proceed.  Perhaps conditionalize the handling
of section header type "0x6ffffff5" based upon the OSABI?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]