labath wrote:
> Note `-ffunction-sections -fdata-sections` are added in
> HandleLLVMOptions.cmake and `-Wl,--gc-sections` is added in AddLLVM.cmake by
> default. But unused functions will be kept anyway if they contain linker gc
> roots. A lot of functions in CPlusPlusLanguage.cpp contain static variables
> like
>
> ```
> CPlusPlusLanguage::GetHardcodedSummaries() {
> static llvm::once_flag g_initialize;
> ```
I don't think it's as simple as that. I don't see a reason for an
function-local static to be a gc root. In fact, when I look at your example
(thank you for that), I see that none of the code in BlockPointer.cpp is
actually present in the final binary, despite it obviously being somehow
implicated in the size increase.
That said, all of this gives me an idea for a plausible explanation: AIUI,
linking basically works in two stages. First, you determine which object files
are going to be a part of the link. This part works at object file level, and
doesn't do any reachability analysis -- if we see an undefined symbol, we pull
in the object which defines it.
In the second stage (if --gc-sections is used), we remove any
sections/functions which are not reachable from a gc root. Function-local
statics should not be a gc root, but file-level globals definitely are. So any
code that is reachable from global initializer is kept, even though the file
containing the initializer was only referenced through dead code.
Global variables are
[banned](https://llvm.org/docs/CodingStandards.html#do-not-use-static-constructors)
by the coding standards, but I wouldn't be surprised if there were still some
around that cause this.
https://github.com/llvm/llvm-project/pull/132274
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
