On Fri, 2022-04-29 at 13:56 +0200, Jakub Jelinek wrote: > On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote: > > > This doesn't resolve the problem, unfortunately, because > > > references to discarded comdat symbols are still kept in .rodata: > > > > > > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced > > > in > > > section `.rodata' of ../lib/libgtest.a(gtest-all.cc.o): defined > > > in > > > discarded section > > > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_[_ZN7testing15 > > > Asse > > > rt > > > ionResultlsIPKcEERS0_RKT_]' of ../lib/libgtest.a(gtest-all.cc.o) > > > > > > (That's from building zlib-ng with ASan and your patch on s390). > > > > > > So I was rather thinking about adding a reloc parameter to > > > mergeable_constant_section () and slightly changing the section > > > name when it's nonzero, e.g. from .cst to .cstrel. > > > > After some experimenting, I don't think that what I propose here > > is a good solution anymore, since it won't work with > > -fno-merge-constants. > > > > What do you think about something like this? > > > > --- a/gcc/varasm.cc > > +++ b/gcc/varasm.cc > > @@ -7326,6 +7326,10 @@ default_elf_select_rtx_section (machine_mode > > mode, rtx x, > > return get_named_section (NULL, ".data.rel.ro", 3); > > } > > > > + if (reloc) > > + return targetm.asm_out.function_rodata_section > > (current_function_decl, > > + false); > > + > > return mergeable_constant_section (mode, align, 0); > > } > > > > This would put constants with relocations into .rodata.<FUNC>. > > default_function_rodata_section () already ensures that these > > sections > > are in the right comdat group. > > We don't really know if the emitted constant is purely for the > current > function, or also other functions (say emitted in as constant pool > constant > where constant pool constants are shared across the whole TU). > For the former, putting it into current function's comdat is fine, > for the > latter certainly isn't.
mergeable_constant_section (), that the existing code calls in the same context, already relies on this being known and calls function_rodata_section () with exactly the same arguments. If !current_function_decl && !relocatable, we get readonly_data_section. Of course, mergeable_constant_section () does not handle comdat currently, so this point might be moot. However, looking at the callers of output_constant_pool_contents (), it seems that !current_function_decl happens in and only in the shared_constant_pool case, so it looks as if we know whether the constant is tied to a single function or not.
