This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use 1U everywhere in elf/elf.h.
- From: Mark Wielaard <mjw at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Petr Machata <pmachata at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andreas Schwab <schwab at linux-m68k dot org>, Josh Stone <jistone at redhat dot com>
- Date: Thu, 26 Mar 2015 10:30:45 +0100
- Subject: Re: [PATCH] Use 1U everywhere in elf/elf.h.
- Authentication-results: sourceware.org; auth=none
- References: <54F9E0CE dot 8070303 at redhat dot com> <20150306180147 dot 7EA492C3B32 at topped-with-meat dot com> <54FA28D8 dot 1080209 at redhat dot com> <20150306222818 dot 643092C3B39 at topped-with-meat dot com> <54FB4511 dot 2020008 at redhat dot com> <87d23ynm4r dot fsf at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1503242114280 dot 16467 at digraph dot polyomino dot org dot uk>
On Tue, Mar 24, 2015 at 09:23:55PM +0000, Joseph Myers wrote:
> On Tue, 24 Mar 2015, Petr Machata wrote:
> > Would something like the following be acceptable? It builds on
> > known-elf.h/known-elf.awk that I've earlier today proposed for
> > contribution to elfutils.
> > #include <elfutils/known-elf.h>
> I don't think it's a good idea to depend on elfutils on the glibc host (or
> even on the build system). Tests built for the host should avoid
> depending on headers other than kernel headers and those included in
I am sure we can arrange something so that known-elf.awk can be shared or
included into glibc if necessary. It was written to process the elf.h
as is in glibc (elfutils just includes its own copy to make sure it has
the latest definitions, but we don't install it and we want to keep it
in sync with the glibc one - which is why we really want the SHF_EXCLUDE
> So what's the correct type? The obvious type is that of the sh_flags
> field, except that sh_flags has different types (Elf32_Word and
> Elf64_Xword) for 32-bit and 64-bit ELF, so clearly the type can't match
> for one of them. 32-bit unsigned seems appropriate to avoid bogus
> sign-extension in the 64-bit case when the high bit is set.
Would the easiest solution then just be to just use unsigned hex values
for the SHF constants to avoid all the bit shifts?
/* Legal values for sh_flags (section flags). */
#define SHF_WRITE 0x00000001u /* Writable */
#define SHF_ALLOC 0x00000002u /* Occupies memory during execution */
#define SHF_EXECINSTR 0x00000004u /* Executable */
#define SHF_MERGE 0x00000010u /* Might be merged */
#define SHF_STRINGS 0x00000020u /* Contains nul-terminated strings */
#define SHF_INFO_LINK 0x00000040u /* `sh_info' contains SHT index */
#define SHF_LINK_ORDER 0x00000080u /* Preserve order after combining */
#define SHF_OS_NONCONFORMING 0x00000100u /* Non-standard OS specific handling
#define SHF_GROUP 0x00000200u /* Section is member of a group. */
#define SHF_TLS 0x00000400u /* Section hold thread-local data. */
#define SHF_MASKOS 0x0ff00000u /* OS-specific. */
#define SHF_MASKPROC 0xf0000000u /* Processor-specific */
#define SHF_ORDERED 0x40000000u /* Special ordering requirement
#define SHF_EXCLUDE 0x80000000u /* Section is excluded unless
referenced or allocated (Solaris).*/