[LLVMbugs] [Bug 18757] New: __attribute__((section())) not always honored in extern "C" under optimization

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18757

            Bug ID: 18757
           Summary: __attribute__((section())) not always honored in
                    extern "C" under optimization
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mark at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

When a static variable with __attribute__((section())) is placed inside extern
"C", under optimization, the section attribute is not honored.

Consider this small test in C++:

extern "C" {
static const int i __attribute__((used, section("__DATA,__custom"))) = 1;
}  // extern "C"

clang should place the data in the __DATA,__custom section. Instead, under
optimization (-O1 or higher), it places it in the __TEXT,__const section.

My team experienced this problem when creating a __DATA,__interpose section for
dyld interposing on Mac OS X. The interpose data was inadvertently placed
inside an extern "C" block. Since it didn’t need to be extern "C", it was
removed from this block and its __attribute__((section())) was honored
properly.

This problem occurs with qualifiers “static const” and “const” alone (it is
placed in __TEXT,__const), and with “static” alone (it is placed in
__DATA,__data). When using “extern const”, “extern” alone, or no qualifiers, it
is placed in the desired section (__DATA,__custom).

With no optimization (-O0), it is always placed in the desired section
(__DATA,__custom) regardless of qualifiers and regardless of whether it’s
inside an extern "C" block.

Outside of extern "C", regardless of qualifiers, at any optimization level, it
is always properly placed in the desired section (__DATA,__custom). In plain C
mode (no ++), it is also always properly placed in the desired section. (Some
of these combinations do present a -Wextern-initializer warning.)

This bug is present in the current clang trunk (r200925). My Mac’s system copy
of clang, which identifies itself as “Apple LLVM version 5.0 (clang-500.2.79)
(based on LLVM 3.3svn)” from Xcode 5.0.2 5A3005, does not have this bug. I
tested binary builds of clang I had on hand, and the bug is not present in
r182481, but had regressed by r184830.

This example uses data, but similar problems were seen when attempting to place
code into custom sections by decorating function definitions with
__attribute__((section())).

Although the discussion above is obviously Mach-O-specific, this bug is not
limited to Mach-O or Mac. Testing the current clang trunk on Linux, I see the
same bug, with obvious substitutions for the sections used.

Test case:

--
extern "C" {
static const int i __attribute__((used, section("__DATA,__custom"))) = 1;
}
--

Compile with: clang++ -S test.cc -o- -O1

Expect:

--
    .section    __TEXT,__text,regular,pure_instructions
    .section    __DATA,__custom
    .align    2                       ## @i
_i:
    .long    1                       ## 0x1

    .no_dead_strip    _i

.subsections_via_symbols
--

Observe:

--
    .section    __TEXT,__text,regular,pure_instructions
    .section    __TEXT,__const
    .align    2                       ## @i
_i:
    .long    1                       ## 0x1

    .no_dead_strip    _i

.subsections_via_symbols
--

-- 
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/20140206/5eb1bada/attachment.html>