[Bug libc/15794] move AT_* constants definition from elf.h into sysdeps (bits) directory

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15794

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Adam Conrad from comment #7)
> The problem with this patch is that any code that previously included elf.h
> to get the AT_ defines is now broken (*cough*GCC*cough*).  Are you expecting
> that any such code should have an include <sys/auxv.h>, or should elf.h be
> pulling in bits/auxv.h for backward compat?

In my opinion the best way forward is:

(a) Move AT_NULL to AT_ENTRY into sysdeps/generic/bits/auvx-base.h, and
document that these 10 entries are os-independent.

(b) Move all other AT_* entries into sysdeps/unix/sysv/linux/bits/auxv.h. Have
bits/auxv.h include bits/auxv-base.h first. Other OSs can override with their
own bits/auxv.h.

(c) Have elf.h include bits/auxv-base.h (not bits/auxv.h) to provide the
os-independent auxv constants. This should prevent some source breakage and
allow the continued use of AT_NULL to AT_ENTRY Which appear to be the only set
of truly os-independent AT_* constants.

(d) Have sys/auxv.h include bits/auxv.h to make all AT_* constants available
for use with getauxval().

(e) Post those patches to libc-alpha for review, and make sure that you have
gcc, binutils, and gdb patches ready if the changes for (a), (b), and (c) break
any of the core toolchain components.

Once you get consensus from glibc it's easier to go to the other projects and
post patches. If a project uses a constant outside of the general
os-independent range (values 0-10) then you'll need a configure check to
determine if you need to include sys/auxv.h or not. It's probably sufficient to
detect if auxv.h is present, and if it is include it after including elf.h. So
you can crib up a configure check for that and use it for all projects that
need a fix (some of which might already have such a check).

-- 
You are receiving this mail because:
You are on the CC list for the bug.