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

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

[Tatsuyuki Ishi]

Oops, I forgot to add a newline after the subject and the mailer ate the body.
Here is the full description:
---
LLVM's addrsig extension [1] allows the compiler to pass on information
about whether a symbol's address is taken to the linker, which in turns
use this info to perform (safe) Identical Code Folding optimization at
link-time.

This patch adds support for the relevant LLVM assembler directives,
which is a prerequisite for GCC support of the feature.

[1]: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table

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

[Tatsuyuki Ishi]

> So, discard the section on ld -r and objcopy if symbols change?

Actually, this is something I need to take care of. LLD currently uses sh_link=0
as a heuristic for such corrupted entries:

https://github.com/llvm/llvm-project/blob/09c2b7c35af8c4bad39f03e9f60df8bd07323028/lld/ELF/InputFiles.cpp#L540-L554

But if we add the sh_link marking into bfd (patch #3), then it will
silently break again, if I understand correctly.

Does discarding sound good to you?

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

[Fangrui Song]

On Wed, May 25, 2022 at 12:34 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, May 25, 2022 at 12:19:24AM -0700, Fangrui Song wrote:
> > I have to be fair, the design of SHT_LLVM_ADDRSIG has a major problem
> > that it does not work with objcopy and ld -r:
>
> So, discard the section on ld -r and objcopy if symbols change?

In llvm-project, llvm-objcopy does not recognize/discard SHT_LLVM_ADDRSIG.
Both GNU objcopy and llvm-objcopy will set sh_link to 0 for the
unrecognized section.

ld.lld --icf=safe prints a warning [1] for SHT_LLVM_ADDRSIG when
sh_link==0 (--icf=all does not need SHT_LLVM_ADDRSIG).
The users I need to serve use -Wl,--fatal-warnings to convert warnings
to errors, so we need to do   `objcopy --remove-section=.llvm_addrsig`
in a few places.

objcopy discarding SHT_LLVM_ADDRSIG would be more ergonomic, but it
raises a question whether it is better for the user to be aware of the
problem and discard the section by themselves.

[1]: https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/icf-safe.s#L92

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

[Alan Modra]

On Wed, May 25, 2022 at 12:19:24AM -0700, Fangrui Song wrote:
> I have to be fair, the design of SHT_LLVM_ADDRSIG has a major problem
> that it does not work with objcopy and ld -r:

So, discard the section on ld -r and objcopy if symbols change?

-- 
Alan Modra
Australia Development Lab, IBM

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

[Fangrui Song]

On 2022-05-25, Tatsuyuki Ishi via Binutils wrote:
>This patch adds support for the relevant LLVM assembler directives,
>which is a prerequisite for GCC support of the feature.
>
>[1]: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table
>
>

I have to be fair, the design of SHT_LLVM_ADDRSIG has a major problem
that it does not work with objcopy and ld -r:
https://sourceware.org/bugzilla/show_bug.cgi?id=23817
That said, using relocations would greatly increase the size of the
section and the current uleb128 does a good job on decreasing the file
size...

If ld supports SHT_LLVM_ADDRSIG, it would probably make it easier
to assemble `clang -S` output with `as`. Currently, on many targets/Linux
distributions, `clang -S` defaults to -faddrsig which makes the output
not-assembable with `as`.

[PATCH 0/4] gas: Add support for LLVM addrsig and addrsig_sym.

[Tatsuyuki Ishi]

This patch adds support for the relevant LLVM assembler directives,
which is a prerequisite for GCC support of the feature.

[1]: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table