[Lldb-commits] [lldb] [LLDB][NFC] Move CPlusPlusLanguage methods used in Core/Module.cpp to a separated module to break lldb-server dependencies (PR #132274)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Wed Mar 26 01:23:07 PDT 2025


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


More information about the lldb-commits mailing list