Re: [PATCH v2 0/6] gas: Add support for LLVM addrsig and addrsig_sym.

[Fangrui Song <i@maskray.me>]

On Tue, Jun 28, 2022 at 7:56 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Jun 29, 2022 at 10:27:17AM +0900, Tatsuyuki Ishi wrote:
> > You're right. It seems that the way I numbered the symbols wasn't
> > quite right. I'll get it fixed by the next revision.
>
> It isn't going to be easy.  The problem is that elf symbol ordering is
> done by bfd/elf.c:elf_map_symbols, which isn't called until there is
> some file output triggering _bfd_elf_compute_section_file_positions.
> So you can't fill out .llvm_addrsig until quite late, but you need its
> size earlier for layout.  Exact sizing isn't going to be possible due
> to uleb128 ecoding of symbol index.  You can likely get a reasonable
> upper bound.

There has been some discussion on .llvm_addrsig recently:
https://discourse.llvm.org/t/problems-with-mach-o-address-significance-table-generation/63392

Will switching to the relocation-based encoding look like a good idea
for objcopy and ld -r operability?
We can consider replacing the current uleb128 encoding (usually one
byte for one symbol) with a SHT_REL relocation (16 bytes for
Elf64_Rel)

r_offset = 0
r_info = ELF64_R_INFO(sym_idx, R_*_NONE)

I'll do some experiments.