On Wed, 2022-04-27 at 14:46 +0200, Jakub Jelinek wrote: > On Wed, Apr 27, 2022 at 02:23:00PM +0200, Jakub Jelinek wrote: > > On Wed, Apr 27, 2022 at 11:59:49AM +0200, Ilya Leoshkevich wrote: > > > I get a .LASANPC reloc there in the first place because of > > > https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/ > > > but of course it may happen for other reasons as well. > > > > In that case I don't see any benefit to put that into a mergeable > > section. > > Why does that happen? > > Because, when a mergeable section doesn't contain any relocations, I > don't > see any point in making it comdat. Because mergeable sections > themselves > are garbage collected, if some constant isn't referenced at all, it > isn't > emitted, or if referenced, multiple copies of the constant are merged > (or > for mergeable strings even string tail merging is performed). > > Jakub >
This is determined by default_elf_select_rtx_section (). If we don't want to mix non-reloc and reloc constants, we need to define a special section there. It seems to me, however, that this all would be made purely for the sake of .LASANPC, which is quite special: it's local, but at the same time it might need to be comdat. I don't think anything like this can appear from compiling C/C++ code. Therefore I wonder if we could just drop it altogether like this? @@ -1928,22 +1919,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb, ... - emit_move_insn (mem, expand_normal (build_fold_addr_expr (decl))); + emit_move_insn (mem, expand_normal (build_fold_addr_expr (current_function_decl))); ... That's what LLVM is already doing. This will also solve the alignment problem I referred to earlier.
