[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(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

> 
> 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.

> 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?