Messages in this thread | | | Date | Mon, 7 Jun 2021 09:56:48 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls |
| |
On Sat, Jun 05, 2021 at 06:58:39PM -0700, Fāng-ruì Sòng wrote: > On Sat, Jun 5, 2021 at 3:39 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > I think you've absolutely nailed it; but would you have more information > > or a code reference to what you're speaking about? My complete ELF > > and libelf knowledge is very limited and as demonstrated here, I'm not > > at all sure how all that extended index stuff is supposed to work. > > The section index field of an Elf{32,64}_Sym (st_shndx) is 16-bit, so > it cannot represent a section index greater than 0xffff. > ELF actually reserves values in 0xff00~0xff00 for other purposes, so > st_shndx cannot represent a section whose index is greater or equal to > 0xff00.
Right, that's about as far as I got, but never could find details on how the extension worked in detail, and I clearly muddled it :/
> To overcome the 16-bit section index limitation, .symtab_shndx was designed. > > http://www.sco.com/developers/gabi/latest/ch4.symtab.html says > > > SHN_XINDEX This value is an escape value. It indicates that the > > symbol refers to a specific location within a section, but that the > > section header index for that section is too large to be represented > > directly in the symbol table entry. The actual section header index > > is found in the associated SHT_SYMTAB_SHNDX section. The entries in > > that section correspond one to one with the entries in the symbol > > table. Only those entries in SHT_SYMTAB_SHNDX that correspond to > > symbol table entries with SHN_XINDEX will hold valid section header > > indexes; all other entries will have value 0. > > You may use https://github.com/llvm/llvm-project/blob/main/llvm/tools/llvm-objcopy/ELF/Object.cpp#L843 > as a reference.
Excellent, lemme go read up and attempt to fix this.
| |