https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #11 from Andrey Drobyshev <a.drobyshev at samsung dot com> ---
(In reply to Martin Liška from comment #9)
> (In reply to Andrey Drobyshev from comment #8)
>
> Great you've been working on that Andrey.
>
> > 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
>
> Can you please provide work-in-progress patch so that I can play with that?
> Is your patch also handling the comment:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c4
>
I guess it's not. I was only able to test this thing on x86_64 and armv7l.
> >
> > 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.
>
> I can investigate once I have a patch candidate.
>
Please see attachment above.
> > 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.
>
> @Jakub: Can you advise please about the question #2?
>
These questions remain unanswered...
