This is the mail archive of the libc-help@sourceware.org mailing list for the glibc 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]

Re: How to implement a kernel feature check in the crt* files?


> 1. Put a flag into the e_flags field of the elf header.

This is the sort of thing that e_flags is there for.

> 1b The auxiliary vector does contain the address of the segment
> headers in memory.  Currently ld always arranges that the elf header
> resides directly before that address.  Using that address to locate
> the elf header would break immediately if the elf header gets
> extended.  Heuristics like rounding the address down to a page or
> checking the elf magic might help. But it stays - well - a heuristic.

There is a reliable method using AT_PHDR.  Find the first PT_LOAD with
p_offset=0 (in practice it's always the first there is) and its p_vaddr
is where the ELF header appears in memory.

> 2. Put a flag into the .note.gnu.hwcaps section.
> 
> That section can be found scanning the segment headers from _start.
> There seem to be support for NT_GNU_HWCAPS in glibc as well as
> binutils but without any user yet.  Is that mechanism supposed to work
> already?  Does anybody know who might already make use of it?

This note has one special purpose and it's not for what you want at all.
It's only used in a vDSO, to let the vDSO supply new strings to be treated
as if they were known hwcap bits for purposes of library search directories
(and corresponding ld.so.cache bits).  It has nothing to do with real hwcaps.

> 3. Use the .note.ABI-tag set.
> 
> Again that segment should be easy to locate in memory by scanning the
> segment headers pointed to by AT_PHDR.

It is easy to find all the PT_NOTE's that way, and then you have to examine
the note format in each one to find a particular note you are looking for.

> The ABI-tag specifies the a required kernel version for the binary and
> at least for DSOs there seem to be a check in glibc which prevents
> them from being used on older kernels.  I didn't found that for
> executables.  Only the dynamic loader seem to care about that - is
> that correct?

Yes.  I don't think it is appropriate to conflate machine-level issues with
this.  If you want to use a note, add a new one.

> The assembler could put in 2.6.32 as required kernel version here
> assuming that kernels with at least that version provide the needed
> feature.

That is not appropriate for the assembler to be doing.  There is nothing
magical at the toolchain level about this note.  It's just part of crt1.o
as supplied by glibc.  You don't get to choose which crt1.o you want or
which notes go into it based on what the assembler thinks.

> What would be a reasonable approach?  Perhaps there is something much
> better I'm completely ignoring so far.

e_flags is the right thing.


Thanks,
Roland


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