[llvm-dev] [ELF] String literals don't obey -fdata-sections
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 17 03:20:14 PDT 2020
I've not looked at the GNU behaviour, but the purpose of -fdata-sections in
my experience is to provide the ability to do section-level operations like
--gc-sections, --icf, symbol ordering etc. SHF_MERGE sections, such as
.rodata string and integer literal sections, are internally fragmentable by
the linker using rules defined by the ABI, so a linker can already easily
strip them without -fdata-sections splitting them up. LLD does this, and I
don't see why other linkers couldn't either (obviously this might require
the functionality to be implemented properly in those linkers).
Input section overhead is a big deal, based on experiments I've recently
been doing, both because of the additional incurred I/O and the time it
takes in the linker to process the additional sections. If an object has
many literals, this will drastically bloat the input size, which imposes a
cost on people who want to be able to do proper --gc-sections [--icf etc]
who use LLD, for no gain.
On Thu, 17 Sep 2020 at 09:38, Gaël Jobin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2020-09-16 19:42, Fangrui Song wrote:
>
> On 2020-09-16, Gaël Jobin wrote:
>
> Your example uses global mutable variables "test" and "unused" and that
> is why they are in the .data.* sections. They are initialized to
> addresses of string literals in .rodata.* . .rodata.* are what we care
> about, not .data.* (.data.* can always be correctly garbage collected by
> GNU ld/gold/LLD).
>
>
> Of course, the issue here is .rodata.*. I use the .data.* section as a
> counterexample
> but it could be any section. I compare those two sections because they
> contain both
> small datas and the ratio "section header size" vs "data size" is not
> optimal.
>
> But my point is: Why the implementation of -fdata-sections should differ
> between .data.*
> and .rodata.* sections? Or why .rodata.* should be treated differently?
>
> If the only reason is because it is suboptimal due to the additional
> section header,
> this is definitely not a valid reason. Having everything in its own
> section is the
> purpose of the -f*-sections and allows the linker to easily strip them. I
> really
> don't get the exception made for .rodata.* here.
>
>
>
> _______________________________________________
> 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/20200917/51d0d85e/attachment.html>
More information about the llvm-dev
mailing list