With most 0.14x versions, last confirmed with 0.151, run-elflint-self.sh fails with many messages such as:
section [ 5] '.dynsym': symbol 61: unknown bit set in st_other section [ 5] '.dynsym': symbol 64: unknown bit set in st_other section [28] '.symtab': symbol 27: unknown bit set in st_other section [28] '.symtab': symbol 34: unknown bit set in st_other section [28] '.symtab': symbol 35: unknown bit set in st_other section [28] '.symtab': symbol 36: unknown bit set in st_other section [28] '.symtab': symbol 37: unknown bit set in st_other section [28] '.symtab': symbol 38: unknown bit set in st_other section [28] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x120014010 does not match .got section address 0x120014000
Full build logs are available at https://bugs.gentoo.org/329875
section [ 5] '.dynsym': symbol 61: unknown bit set in st_other section [ 5] '.dynsym': symbol 64: unknown bit set in st_other section [28] '.symtab': symbol 27: unknown bit set in st_other section [28] '.symtab': symbol 34: unknown bit set in st_other section [28] '.symtab': symbol 35: unknown bit set in st_other section [28] '.symtab': symbol 36: unknown bit set in st_other section [28] '.symtab': symbol 37: unknown bit set in st_other section [28] '.symtab': symbol 38: unknown bit set in st_other section [28] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x120014010 does not match .got section address 0x120014000
These indicate either bugs in the compilation tools (probably ld) or else machine-specific oddities that the elfutils backend library for alpha needs to be taught to allow. We can help figure out the details if you supply us with one of the binaries that gets these messages.
Thanks, Roland
On 03/09/2011 11:17 AM, Roland McGrath wrote:
section [ 5] '.dynsym': symbol 61: unknown bit set in st_other section [ 5] '.dynsym': symbol 64: unknown bit set in st_other section [28] '.symtab': symbol 27: unknown bit set in st_other section [28] '.symtab': symbol 34: unknown bit set in st_other section [28] '.symtab': symbol 35: unknown bit set in st_other section [28] '.symtab': symbol 36: unknown bit set in st_other section [28] '.symtab': symbol 37: unknown bit set in st_other section [28] '.symtab': symbol 38: unknown bit set in st_other section [28] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x120014010 does not match .got section address 0x120014000
These indicate either bugs in the compilation tools (probably ld) or else machine-specific oddities that the elfutils backend library for alpha needs to be taught to allow.
The later. From <elf.h>:
/* Legal values for st_other field of Elf64_Sym. */ #define STO_ALPHA_NOPV 0x80 /* No PV required. */ #define STO_ALPHA_STD_GPLOAD 0x88 /* PV only used for initial ldgp. */
As for the _G_O_T_ symbol value, there's no reason for the value to even be within the .got section; the value may be offset by +- 32k to aid indexing. Further, Alpha supports multiple .got subsections, such that _G_O_T_ does not represent a global value across the entire DSO. Honestly there's no reason to check this on Alpha.
r~
On Wed, 2011-03-09 at 12:03 +1100, Richard Henderson wrote:
On 03/09/2011 11:17 AM, Roland McGrath wrote:
section [ 5] '.dynsym': symbol 61: unknown bit set in st_other section [ 5] '.dynsym': symbol 64: unknown bit set in st_other section [28] '.symtab': symbol 27: unknown bit set in st_other section [28] '.symtab': symbol 34: unknown bit set in st_other section [28] '.symtab': symbol 35: unknown bit set in st_other section [28] '.symtab': symbol 36: unknown bit set in st_other section [28] '.symtab': symbol 37: unknown bit set in st_other section [28] '.symtab': symbol 38: unknown bit set in st_other section [28] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x120014010 does not match .got section address 0x120014000
These indicate either bugs in the compilation tools (probably ld) or else machine-specific oddities that the elfutils backend library for alpha needs to be taught to allow.
The later. From <elf.h>:
/* Legal values for st_other field of Elf64_Sym. */ #define STO_ALPHA_NOPV 0x80 /* No PV required. */ #define STO_ALPHA_STD_GPLOAD 0x88 /* PV only used for initial ldgp. */
If you are using these, should ELF64_ST_VISIBILITY be extended? Also from <elf.h>:
/* How to extract and insert information held in the st_other field. */
#define ELF32_ST_VISIBILITY(o) ((o) & 0x03)
/* For ELF64 the definitions are the same. */ #define ELF64_ST_VISIBILITY(o) ELF32_ST_VISIBILITY (o)
That is what elflint checks here.
Cheers,
Mark
/* Legal values for st_other field of Elf64_Sym. */ #define STO_ALPHA_NOPV 0x80 /* No PV required. */ #define STO_ALPHA_STD_GPLOAD 0x88 /* PV only used for initial ldgp. */
If you are using these, should ELF64_ST_VISIBILITY be extended?
No, these are not visibility flags. What we need here is a new ebl hook to let the backend accept more st_other bits.
Thanks, Roland
On Wed, 2011-03-09 at 10:12 -0800, Roland McGrath wrote:
/* Legal values for st_other field of Elf64_Sym. */ #define STO_ALPHA_NOPV 0x80 /* No PV required. */ #define STO_ALPHA_STD_GPLOAD 0x88 /* PV only used for initial ldgp. */
If you are using these, should ELF64_ST_VISIBILITY be extended?
No, these are not visibility flags. What we need here is a new ebl hook to let the backend accept more st_other bits.
Something like:
/* Check whether only valid bits are set on the st_other symbol flag. */ bool ebl_check_st_other_bits (Ebl *ebl, unsigned char st_other);
I got a patch for that on the mjw/ebl_special_other branch. Hope I hooked things up correctly.
Cheers,
Mark
It probably makes sense for the hook to get all the arguments that check_special_symbol gets too, so it can check some details of the specific symbol rather than just generically for known bits. Hmm, perhaps even just having check_special_symbol do this would be OK too, though that might be too coarse since it's used in several places. If it is a new hook, then it might be better for it to get st_other & ~GELF_ST_VISIBILITY so that the backend only has to check for the machine-specific bits instead of also encoding the generic knowledge.
Thanks, Roland
On Thu, 2011-03-10 at 09:28 -0800, Roland McGrath wrote:
It probably makes sense for the hook to get all the arguments that check_special_symbol gets too, so it can check some details of the specific symbol rather than just generically for known bits. Hmm, perhaps even just having check_special_symbol do this would be OK too, though that might be too coarse since it's used in several places.
Yeah, that seems overkill, since all it really does is check whether the bit pattern is acceptable. check_special_symbol could get new functionality added, but that only makes sense if you also check other semantics, which we aren't doing here.
If it is a new hook, then it might be better for it to get st_other & ~GELF_ST_VISIBILITY so that the backend only has to check for the machine-specific bits instead of also encoding the generic knowledge.
yes, good point. I made that change on the mjw/ebl_special_other branch. OK the merge to trunk?
Thanks,
Mark
yes, good point. I made that change on the mjw/ebl_special_other branch. OK the merge to trunk?
I guess it's OK. It would make more sense to me if the default function did the check for zero rather than that being done outside the backend. The libebl interface is intentionally not a stable API, so we can always change it again later.
Thanks, Roland
As for the _G_O_T_ symbol value, there's no reason for the value to even be within the .got section; the value may be offset by +- 32k to aid indexing. Further, Alpha supports multiple .got subsections, such that _G_O_T_ does not represent a global value across the entire DSO. Honestly there's no reason to check this on Alpha.
I made it accept any value though it will still check that the st_shndx is in .got. If it's really necessary to disarm that part of the check as well, we'll have to change the generic part of elflint to let the backend control that.
Thanks, Roland
elfutils-devel@lists.fedorahosted.org