On Wed, 2022-04-27 at 11:59 +0200, Ilya Leoshkevich via Gcc-patches
wrote:
> On Wed, 2022-04-27 at 11:33 +0200, Jakub Jelinek wrote:
> > On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-
> > patches wrote:
> > > Bootstrapped and regtested on x86_64-redhat-linux and
> > > s390x-redhat-linux. Ok for master (or GCC 13 in case this
> > > doesn't
> > > fit
> > > stage4 criteria)?
> >
> > I'd prefer to defer this to GCC 13 at this point.
> > Furthermore, does the linker then actually merge the constants with
> > the same constants from other mergeable linkonce sections or other
> > mergeable sections? I'm afraid it would only merge constants
> > within
> > each comdat group and not across the whole ELF object.
> >
> > Jakub
> >
>
> I experimented with this a little, and actually having a reloc
> prevents
> merging altogether (the check happens in _bfd_add_merge_section).
>
> 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.
I just realized I forgot to mention the "normal" case.
There, "aMG" seems to works fine with the whole ELF:
$ cat 1.s
.globl _start
_start:
ret
.section .rodata.xxx,"aMG",@progbits,8,.xxx,comdat
.quad 42
$ cat 2.s
.section .rodata.yyy,"aMG",@progbits,8,.yyy,comdat
.quad 42
.quad 43
.section .rodata.xxx,"aMG",@progbits,8,.xxx,comdat
.quad 42
$ gcc -nostartfiles -fPIE 1.s 2.s
$ objdump -D a.out
0000000000002000 <.rodata>:
2000: 2a 00 sub (%rax),%al
2002: 00 00 add %al,(%rax)
2004: 00 00 add %al,(%rax)
2006: 00 00 add %al,(%rax)
2008: 2b 00 sub (%rax),%eax
200a: 00 00 add %al,(%rax)
200c: 00 00 add %al,(%rax)
...
