https://llvm.org/bugs/show_bug.cgi?id=26570
Bug ID: 26570
Summary: incomplete support for -fdata-sections in clang/llvm
for C++ static data members
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: th...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15875
--> https://llvm.org/bugs/attachment.cgi?id=15875&action=edit
test case
The attached test case and makefile illustrate a limitation in the current
clang/llvm implementation of the "-fdata-sections" command line option. This
option tells the compiler to place each named data item into a separate ELF
section in the resulting object file; doing this has benefits in that it helps
enable linker GC of unused sections and (if desired) linker reordering of
sections for performance/size reasons.
In the test case ("ex.cc") note the following two variables:
char foo::ID = 0;
char baz::ID = 0;
When you compile with -fdata-sections, these two vars are still placed into the
same ".bss" section, which effectively defeats the option.
To illustrate why this is a problem, download the testcase + makefile and run
"make doit", then diff the two files
ex.so.od.clang.txt ex.so.od.gcc.txt
For gcc (which doesn't make the same mistake), the linker is able to
garbage-collect the storage for "_ZN12_GLOBAL__N_13foo2IDE", whereas in the
LLVM case this dead storage can't be reclaimed (since the var in question is in
the same section with another variable that is not dead).
NB: there maybe other cases in which -fdata-sections also doesn't work (I
haven't done an exhaustive search). It does seem to work ok for C-style
variable declarations as far as I can tell.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
