llvm dev - Mar 2021 - [RFC] Annotating global functions and variables to prevent ICF during linking

Hi all,

Background:
It's been a longstanding difficulty of debugging with ICF. Programmers
don't have control over which sections should be folded by ICF, which
sections shouldn't. The existing address significant table won't have
effect for code sections during all ICF mode in both ld.lld and lld-link.
By switching to safe ICF could mark code sections as unique, but at a cost
of increasing binary size out of control. So, it would be good if
programmers could selectively disable ICF in source code by annotating
global functions/variables with an attribute to improve debugging
experience and have the control on the binary size increase.

My plan is to add a new section table(`.no_icf`) to object files. Sections
of all symbols inside the table should not be folded by all ICF mode. And
symbols can only be added into the table by annotating global
functions/variables with a new attribute(`no_icf`) in source code.

What do you think about this approach?

Thanks,
Zequan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210322/bf422600/attachment.html>

+Peter Collingbourne <pcc at google.com> +Fangrui Song <maskray at
google.com>

I'm also not sure I understand. Perhaps an example? i.e. how does the
current system not work here in safe mode?

-eric

On Mon, Mar 22, 2021 at 8:27 PM Zequan Wu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> Background:
> It's been a longstanding difficulty of debugging with ICF. Programmers
> don't have control over which sections should be folded by ICF, which
> sections shouldn't. The existing address significant table won't
have
> effect for code sections during all ICF mode in both ld.lld and lld-link.
> By switching to safe ICF could mark code sections as unique, but at a cost
> of increasing binary size out of control. So, it would be good if
> programmers could selectively disable ICF in source code by annotating
> global functions/variables with an attribute to improve debugging
> experience and have the control on the binary size increase.
>
> My plan is to add a new section table(`.no_icf`) to object files. Sections
> of all symbols inside the table should not be folded by all ICF mode. And
> symbols can only be added into the table by annotating global
> functions/variables with a new attribute(`no_icf`) in source code.
>
> What do you think about this approach?
>
> Thanks,
> Zequan
>
> _______________________________________________
> 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/20210322/5041c51b/attachment-0001.html>

Can you define ICF please?  And give a bit of context?

Philip

On 3/22/21 5:27 PM, Zequan Wu via llvm-dev wrote:
> Hi all,
>
> Background:
> It's been a longstanding difficulty of debugging with ICF. Programmers 
> don't have control over which sections should be folded by ICF, which 
> sections shouldn't. The existing address significant table won't
have
> effect for code sections during all ICF mode in both ld.lld and 
> lld-link. By switching to safe ICF could mark code sections as unique, 
> but at a cost of increasing binary size out of control. So, it would 
> be good if programmers could selectively disable ICF in source code by 
> annotating global functions/variables with an attribute to improve 
> debugging experience and have the control on the binary size increase.
>
> My plan is to add a new section table(`.no_icf`) to object files. 
> Sections of all symbols inside the table should not be folded by all 
> ICF mode. And symbols can only be added into the table by annotating 
> global functions/variables with a new attribute(`no_icf`) in source code.
>
> What do you think about this approach?
>
> Thanks,
> Zequan
>
>
> _______________________________________________
> 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/20210322/bc7d22a5/attachment.html>