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