https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
Andrey Drobyshev <a.drobyshev at samsung dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |a.drobyshev at samsung dot com
--- Comment #8 from Andrey Drobyshev <a.drobyshev at samsung dot com> ---
I recently started to work on this issue as well. I managed to put a dummy
global variable into .data, .rodata and .bss as follows:
static void
emit_globals_protector(void)
{
tree decl, id, init;
id = get_identifier ("__asan_dummy_global");
decl = build_decl (BUILTINS_LOCATION, VAR_DECL, id, integer_type_node);
init = build_one_cst(integer_type_node);
SET_DECL_ASSEMBLER_NAME (decl, id);
TREE_ADDRESSABLE (decl) = 1;
DECL_ARTIFICIAL (decl) = 1;
TREE_STATIC (decl) = 1;
TREE_PUBLIC (decl) = 1;
TREE_USED (decl) = 1;
TREE_READONLY (init) = 1; // controls whether variable goes to .rodata
or .data
TREE_STATIC (init) = 1;
DECL_INITIAL (decl) = init; // controls whether variable gets initialized
or goes to .bss
varpool_node::add(decl);
}
Calling varpool_node::add() makes sure that created dummy global goes first
into the target section, as it leads to call to assemble_variable():
#0 categorize_decl_for_section (decl=0x7ffff7ff4e10, reloc=0) at
../../gcc/varasm.c:6378
#1 0x0000000001096112 in default_elf_select_section (decl=0x7ffff7ff4e10,
reloc=0, align=256) at ../../gcc/varasm.c:6499
#2 0x00000000010b6ce3 in x86_64_elf_select_section (decl=0x7ffff7ff4e10,
reloc=0, align=256) at ../../gcc/config/i386/i386.c:6549
#3 0x000000000108afd3 in get_variable_section (decl=0x7ffff7ff4e10,
prefer_noswitch_p=false) at ../../gcc/varasm.c:1170
#4 0x000000000108d70b in assemble_variable (decl=0x7ffff7ff4e10, top_level=0,
at_end=1, dont_output_data=0) at ../../gcc/varasm.c:2206
#5 0x000000000109fd8a in varpool_node::assemble_decl (this=0x7ffff7281100) at
../../gcc/varpool.c:582
#6 0x0000000000917f92 in varpool_node::finalize_decl (decl=0x7ffff7ff4e10) at
../../gcc/cgraphunit.c:823
#7 0x000000000109f9c0 in varpool_node::add (decl=0x7ffff7ff4e10) at
../../gcc/varpool.c:473
#8 0x000000000091ba93 in emit_globals_protector () at
../../gcc/cgraphunit.c:2187
#9 0x000000000091bab6 in output_in_order (no_reorder=false) at
../../gcc/cgraphunit.c:2218
#10 0x000000000091c4f4 in symbol_table::compile (this=0x7ffff71280a8) at
../../gcc/cgraphunit.c:2524
#11 0x000000000091c73f in symbol_table::finalize_compilation_unit
(this=0x7ffff71280a8) at ../../gcc/cgraphunit.c:2620
#12 0x0000000000d90fbf in compile_file () at ../../gcc/toplev.c:496
#13 0x0000000000d93448 in do_compile () at ../../gcc/toplev.c:1998
#14 0x0000000000d936d2 in toplev::main (this=0x7fffffffdbb0, argc=27,
argv=0x7fffffffdcb8) at ../../gcc/toplev.c:2106
#15 0x00000000016e11d1 in main (argc=27, argv=0x7fffffffdcb8) at
../../gcc/main.c:39
However, there're questions:
1. I wonder is it really possible to emit zero-sized dummies and initialize
them as well (i.e. emit them into .data/.rodata)? For now I emit variables of
integer types, but that leads to the presence of couple addressable bytes in
the beginning of the section.
2. What should we do with sections like .data.rel.ro, .data.rel.ro.local? They
suffer from this bug too, but it's not that easy to put globals there, as you
must set various attributes onto decl to ensure it will receive the right reloc
value.
