[llvm-bugs] [Bug 26570] New: incomplete support for -fdata-sections in clang/llvm for C++ static data members

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: thanm at google.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160210/975803c6/attachment.html>