Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Dec 2008 14:37:02 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        dchagin@freebsd.org
Cc:        arch@freebsd.org
Subject:   Re: Removing some cruft...
Message-ID:  <20081217.143702.-1286520955.imp@bsdimp.com>
In-Reply-To: <20081217172047.GA2884@dchagin.dialup.corbina.ru>
References:  <20081216212746.GA28834@freebsd.org> <20081216.161638.644659879.imp@bsdimp.com> <20081217172047.GA2884@dchagin.dialup.corbina.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20081217172047.GA2884@dchagin.dialup.corbina.ru>
            Chagin Dmitry <dchagin@freebsd.org> writes:
: Hi, I am ready to offer more radical patch :)
: 
: Move all Linux aux entry types to a new file compat/linux/linux_elf.h
: Add two new aux entries which improve work of futexes.
: 
: Please review. thnx!
: 
: diff --git a/sys/amd64/include/elf.h b/sys/amd64/include/elf.h
: index a4c7f79..3c2cd20 100644
: --- a/sys/amd64/include/elf.h
: +++ b/sys/amd64/include/elf.h
: @@ -81,16 +81,8 @@ __ElfType(Auxinfo);
:  #define	AT_BASE		7	/* Interpreter's base address. */
:  #define	AT_FLAGS	8	/* Flags (unused for i386). */
:  #define	AT_ENTRY	9	/* Where interpreter should transfer control. */
: -/*
: - * The following non-standard values are used in Linux ELF binaries.
: - */
: -#define	AT_NOTELF	10	/* Program is not ELF ?? */
: -#define	AT_UID		11	/* Real uid. */
: -#define	AT_EUID		12	/* Effective uid. */
: -#define	AT_GID		13	/* Real gid. */
: -#define	AT_EGID		14	/* Effective gid. */
:  
: -#define	AT_COUNT	15	/* Count of defined aux entry types. */

It turns out that these are not non-standard Linux values.  SYSV
also uses these, and the MIPS ABI defines them as well.  Let's leave
them in place.  It may make sense to move these AT_ definitions to a
more central location, however, since I think they are the same on all
platforms.  A quick grep of the Binutils directory seems to support
this, but I only have the MIPS ABI specs.

I also think that we should be exporting them in the normal path, but
that may open up a can of warms so needs to be tested/reviewed
carefully before we pull the trigger.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081217.143702.-1286520955.imp>