How to handle symbol indexes in gas and ld.bfd ?

Greg McGary gkm@rivosinc.com
Mon Apr 3 16:07:58 GMT 2023


I am implementing the RISCV Zisslpcfi extension. Without going into context
&
rationale for the new section, I will go straight to implementation
challenges.

I have a new section named .riscv.zisslpcfi_lp that contains a vector of
pairs
(<symbol>, <label>). <symbol> is represented as an index into the symbol
table--the same way that symbol references are represented in relocation
records--and <label> is a 32-bit integer.

The .riscv.zisslpcfi_lp section is ...

1) written by gas,
   resolving asymbol* to symndx

2) read & parsed by ld.bfd,
   resolving input symndx to riscv_elf_link_hash_entry*

3) written by ld.bfd when the output is relocatable,
   resolving riscv_elf_link_hash_entry* to output symndx

#1 is easy: write from _bfd_riscv_elf_set_section_contents() which
uses _bfd_elf_symbol_from_bfd_symbol() to get the symndx

#2 is easy: from _bfd_riscv_elf_merge_private_bfd_data(), parse
symndx and retrieve the symbol hash entry via
sym_hashes[symndx - symtab_hdr->sh_info]

#3 seems impossible without refactoring. There is no API for mapping
a symbol hash entry to its output symndx. The relocation code, which
also needs to transform input symndx into output symndx, does it
within elf_link_input_bfd() via the temporary flinfo->indices[] vector.

Moreover, gas internally uses asymbol* (struct bfd_symbol) while ld.bfd
uses symbol hash entries, which presents challenges for writing a generic
_bfd_riscv_elf_set_section_contents()

G


More information about the Binutils mailing list