llvm dev - May 2021 - [RFC] Changing .llvm.call-graph-profile to use relocations

On 2021-05-26, Alexander Yermolovich wrote:
>Currently when .llvm.call-graph-profile is created by llvm it explicitly
encodes the symbol indices. This section is basically a black box for post
processing tools. For example, if we run strip -s on the object files the symbol
table changes, but indices in that section do not.
>
>We propose to change this section to use relocations. The Frequency will
still be in the .llvm.call-graph-profile, but symbol information will be in
relocation section. In LLD information from both sections is used to reconstruct
call graph profile. Relocations themselves will never be applied.
Yes, a relocation based approach will be more robust and can fix the
.llvm_addrsig issue https://sourceware.org/bugzilla/show_bug.cgi?id=23817

The relocation type doesn't matter. Your implementation uses R_X86_64_32 and
from/to/value/from/to/value/from/to/value
An alternative design is R_X86_64_NONE + value/value/value, i.e. from/to do not
occupy space in the content.
We will get a 3x space saving.

We need to change the section type since changing representation is incompatible
and the sections from old object files should be ignored.
The new section type will be ignored by old LLVM tools as well.
>With this approach post processing tools that handle relocations correctly
work for this section also.
>
>One thing is section is marked with SHF_EXCLUDE.
>From spec
>"This section is excluded from input to the link-edit of an executable
or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if
relocations exist against the section."
>
>So technically speaking it needs to be kept, and presumably relocations
applied, but LLD follows gold and ld and discards sections marked as SHF_EXCLUDE
even with relocations. So, I think this approach should be fine.
https://reviews.llvm.org/D24966
This is Solaris's spec (since 1996), not standard ELF's.  It can be
advisory but
our behavior (mostly GNU ABI+Linux ABI+LLVM extensions) does not necessarily
follow it.  I cannot find a definition in the x86-64 psABI or a GNU ABI
document.

I think the behavior as implemented in gold and LLD is more useful.
>Finally, this bug seems similar to
https://sourceware.org/bugzilla/show_bug.cgi?id=23817. Proposed solution for
that was also to use relocations.
>
>Implementation: https://reviews.llvm.org/D103212

Thank you for feedback, let me try to use R_X86_64_NONE, and introduce another
type. . I thought R_X86_64_32 would be less impactful as structure of is
preserved, but it is space wasteful.
For type name: ELF::SHT_LLVM_CALL_GRAPH_PROFILE_RELA ?

Alex
________________________________
From: maskray at google.com <maskray at google.com>
Sent: Wednesday, May 26, 2021 5:03 PM
To: Alexander Yermolovich <ayermolo at fb.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Wenlei He
<wenlei at fb.com>; Modi Mo <modimo at fb.com>; dblaikie at
gmail.com <dblaikie at gmail.com>
Subject: Re: [RFC] Changing .llvm.call-graph-profile to use relocations

On 2021-05-26, Alexander Yermolovich wrote:
>Currently when .llvm.call-graph-profile is created by llvm it explicitly
encodes the symbol indices. This section is basically a black box for post
processing tools. For example, if we run strip -s on the object files the symbol
table changes, but indices in that section do not.
>
>We propose to change this section to use relocations. The Frequency will
still be in the .llvm.call-graph-profile, but symbol information will be in
relocation section. In LLD information from both sections is used to reconstruct
call graph profile. Relocations themselves will never be applied.
Yes, a relocation based approach will be more robust and can fix the
.llvm_addrsig issue https://sourceware.org/bugzilla/show_bug.cgi?id=23817

The relocation type doesn't matter. Your implementation uses R_X86_64_32 and
from/to/value/from/to/value/from/to/value
An alternative design is R_X86_64_NONE + value/value/value, i.e. from/to do not
occupy space in the content.
We will get a 3x space saving.

We need to change the section type since changing representation is incompatible
and the sections from old object files should be ignored.
The new section type will be ignored by old LLVM tools as well.
>With this approach post processing tools that handle relocations correctly
work for this section also.
>
>One thing is section is marked with SHF_EXCLUDE.
>From spec
>"This section is excluded from input to the link-edit of an executable
or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if
relocations exist against the section."
>
>So technically speaking it needs to be kept, and presumably relocations
applied, but LLD follows gold and ld and discards sections marked as SHF_EXCLUDE
even with relocations. So, I think this approach should be fine.
https://reviews.llvm.org/D24966
This is Solaris's spec (since 1996), not standard ELF's.  It can be
advisory but
our behavior (mostly GNU ABI+Linux ABI+LLVM extensions) does not necessarily
follow it.  I cannot find a definition in the x86-64 psABI or a GNU ABI
document.

I think the behavior as implemented in gold and LLD is more useful.
>Finally, this bug seems similar to
https://sourceware.org/bugzilla/show_bug.cgi?id=23817 . Proposed solution for
that was also to use relocations.
>
>Implementation: https://reviews.llvm.org/D103212
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210527/8294cbe0/attachment.html>

My understanding is that both call graph info and addrsig info use symbol
table indices because they are considerably smaller than relocations (4
bytes vs 3x pointers, or something). Won't switching to relocations
increase object file size?

I think the approach was inspired by some COFF sections, where this
technique is used to mark safe exception handlers, address-taken functions,
longjmp targets, and other things. MSVC doesn't have a strip utility, so
the only tool you need to handshake with is the linker.

On Wed, May 26, 2021 at 5:04 PM maskray at google.com via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2021-05-26, Alexander Yermolovich wrote:
> >Currently when .llvm.call-graph-profile is created by llvm it
explicitly
> encodes the symbol indices. This section is basically a black box for post
> processing tools. For example, if we run strip -s on the object files the
> symbol table changes, but indices in that section do not.
> >
> >We propose to change this section to use relocations. The Frequency
will
> still be in the .llvm.call-graph-profile, but symbol information will be in
> relocation section. In LLD information from both sections is used to
> reconstruct call graph profile. Relocations themselves will never be
> applied.
>
> Yes, a relocation based approach will be more robust and can fix the
> .llvm_addrsig issue https://sourceware.org/bugzilla/show_bug.cgi?id=23817
>
> The relocation type doesn't matter. Your implementation uses
R_X86_64_32
> and from/to/value/from/to/value/from/to/value
> An alternative design is R_X86_64_NONE + value/value/value, i.e. from/to
> do not occupy space in the content.
> We will get a 3x space saving.
>
> We need to change the section type since changing representation is
> incompatible
> and the sections from old object files should be ignored.
> The new section type will be ignored by old LLVM tools as well.
>
> >With this approach post processing tools that handle relocations
> correctly work for this section also.
> >
> >One thing is section is marked with SHF_EXCLUDE.
> >From spec
> >"This section is excluded from input to the link-edit of an
executable or
> shared object. This flag is ignored if the SHF_ALLOC flag is also set, or
> if relocations exist against the section."
> >
> >So technically speaking it needs to be kept, and presumably relocations
> applied, but LLD follows gold and ld and discards sections marked as
> SHF_EXCLUDE even with relocations. So, I think this approach should be
> fine. https://reviews.llvm.org/D24966
>
> This is Solaris's spec (since 1996), not standard ELF's.  It can be
> advisory but
> our behavior (mostly GNU ABI+Linux ABI+LLVM extensions) does not
> necessarily
> follow it.  I cannot find a definition in the x86-64 psABI or a GNU ABI
> document.
>
> I think the behavior as implemented in gold and LLD is more useful.
>
> >Finally, this bug seems similar to
> https://sourceware.org/bugzilla/show_bug.cgi?id=23817. Proposed solution
> for that was also to use relocations.
> >
> >Implementation: https://reviews.llvm.org/D103212
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210527/e902626d/attachment.html>