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

[Zequan Wu via llvm-dev]

Yes, safe icf mode works by marking all symbols inside .addrsig as unique
if .addrsig table exists or all symbols as unique if .addrsig not exists.
But users don't have precise control over which symbols should be added
into .addrsig to disable folding, which ends up adding a lot unwanted
symbols and increasing binary size out of control.

The approach I post is to let users control which sections should be folded
during all icf mode.

On Mon, Mar 22, 2021 at 5:32 PM Eric Christopher <echristo at gmail.com> wrote:

> +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/dbf017ae/attachment.html>