When providing a variable template with a section attribute its instantiations do not appear in the specified section: ========================================================== template<unsigned x> [[gnu::section(".my_data")]] const unsigned g_my_data {x}; template const unsigned g_my_data<0xf0f0f0f0>; ========================================================== $ g++-7 -c main.cpp -o main.o -std=c++14 $ objdump main.o --full-content main.o: Format elf64-x86-64 Section .group: 0000 01000000 05000000 ........ Section .rodata._Z9g_my_dataILj4042322160EE: 0000 f0f0f0f0 .... Section .comment: 0000 00474343 3a202855 62756e74 7520372e .GCC: (Ubuntu 7. 0010 332e302d 32337562 756e7475 327e3136 3.0-23ubuntu2~16 0020 2e30342e 796f726b 30292037 2e332e30 .04.york0) 7.3.0 0030 00 .
I'm not sure such request can be honored given the section has to be comdat which essentially means it has to have it's own section for each different instantiation. Thus, would we reject template<unsigned x> [[gnu::section(".my_data")]] const unsigned g_my_data {x}; template const unsigned g_my_data<0xf0f0f0f0>; template const unsigned g_my_data<0xf0f0f0f1>; as invalid with an error? Or somehow take .my_data as prefix and mangle it appropriately, assigning it COMDAT? Some things do not make very much sense for C++...
Related bug 70435 Here's a demonstration of the issue with GCC trunk x86-64 on godbolt: https://godbolt.org/z/9GFWZR Minimal example for reproducing: > template<int x> > __attribute__( ( used, section( ".my_section" ) ) ) const int s_value { x }; > > int main( int argc, char * argv[] ) { > return s_value<3>; > } Current behaviour: s_value within section .rodata Desired behaviour: s_value within section .my_section Clang trunk demonstrates the desired behaviour: https://godbolt.org/z/t8FNe0
I also encountered this bug. I started fixing this bug (and PR 70435): https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00348.html
*** Bug 97771 has been marked as a duplicate of this bug. ***
(In reply to Richard Biener from comment #1) > Some things do not make very much sense for C++... I disagree. This definitely makes sense for C++ and it is disappointing that it doesn't work. For instance, this works: [[gnu::used, gnu::section(".my_data")]] inline int data_int; [[gnu::used, gnu::section(".my_data")]] inline double data_double; int& get() { return data_int; } The C++ analogue, necessary for contexts where I may not be able to spell the type in advance, would be this (or a static data member of a class template, same thing): template <typename T> [[gnu::used, gnu::section(".my_data")]] inline T data{}; int& get() { return data<int>; } Except the latter puts data<int> into .bss.data<int>, while the former puts it into .my_data. clang respects the section attribute (https://godbolt.org/z/7137EbxsW), gcc does not (https://godbolt.org/z/548YKjhzn).
Any action on this one? A workaround right now is to change code that would ideally look like (which is pretty clean in my opinion): template <typename T> void foo() { [[gnu::section(".meow")]] static int value = 0; } to code that looks like: template <typename T> void foo() { static int PUT_IN_MEOW_value = 0; } and add a linker script that moves these variables over: .meow : { KEEP(*(SORT(.*PUT_IN_MEOW_*))) } But this is, to put it mildly, less than ideal.
template <typename T> static void foo() { static int PUT_IN_MEOW_value = 0; } When the template function is static, this workaround with linker doesn't work.
Well, additional workaround is to use -fdata-sections. Then the workaround with the linker script works also for the templated static functions and for functions (templated, static) in anonymous namespace (which is another occurrence of this bug).