Message ID | 1483991301-14420-1-git-send-email-adhemerval.zanella@linaro.org |
---|---|
State | New |
Headers | show |
On Mon, Jan 9, 2017 at 2:48 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > GCC has moved from using .gnu.linkonce for i386 setup pic register with > minimum current version (as for binutils minimum binutils that support > comdat). This patch replace linkonce usage by comdat. Is this change compatible with older GCC/binutils versions as well as the new ones? zw
On 09/01/2017 18:26, Zack Weinberg wrote: > On Mon, Jan 9, 2017 at 2:48 PM, Adhemerval Zanella > <adhemerval.zanella@linaro.org> wrote: >> GCC has moved from using .gnu.linkonce for i386 setup pic register with >> minimum current version (as for binutils minimum binutils that support >> comdat). This patch replace linkonce usage by comdat. > > Is this change compatible with older GCC/binutils versions as well as > the new ones? > > zw > I am trying to pinpoint when binutils added comdat support for i686 and this [1] is the oldest thread I found. I also checked with some ancient binutils version and version older than 2.16 I see: test.o: In function `__x86.get_pc_thunk.bx': test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx' /usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here Which seems that the can not handle either comdat at all or the mix of linkonce and comdat. For binutils 2.16.1 and forward I am getting a different issue trying to link a binary with and more recent ctri.o (unrecognized relocation (0x2b) in section `.init', which is R_386_GOT32X and old binutils won't generate it anyway). So I think that either unlikely someone will use an older binutils than the one used to glibc and even this scenario may fail with some issue as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported (glibc itself required 2.22). [1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html
On 10/01/2017 12:02, Adhemerval Zanella wrote: > > > On 09/01/2017 18:26, Zack Weinberg wrote: >> On Mon, Jan 9, 2017 at 2:48 PM, Adhemerval Zanella >> <adhemerval.zanella@linaro.org> wrote: >>> GCC has moved from using .gnu.linkonce for i386 setup pic register with >>> minimum current version (as for binutils minimum binutils that support >>> comdat). This patch replace linkonce usage by comdat. >> >> Is this change compatible with older GCC/binutils versions as well as >> the new ones? >> >> zw >> > > I am trying to pinpoint when binutils added comdat support for i686 and > this [1] is the oldest thread I found. > > I also checked with some ancient binutils version and version older than > 2.16 I see: > > test.o: In function `__x86.get_pc_thunk.bx': > test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here > > Which seems that the can not handle either comdat at all or the mix of > linkonce and comdat. For binutils 2.16.1 and forward I am getting a > different issue trying to link a binary with and more recent ctri.o > (unrecognized relocation (0x2b) in section `.init', which is R_386_GOT32X > and old binutils won't generate it anyway). > > So I think that either unlikely someone will use an older binutils than > the one used to glibc and even this scenario may fail with some issue > as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported > (glibc itself required 2.22). > > [1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html > Ping.
On 17/01/2017 08:24, Adhemerval Zanella wrote: > > > On 10/01/2017 12:02, Adhemerval Zanella wrote: >> >> >> On 09/01/2017 18:26, Zack Weinberg wrote: >>> On Mon, Jan 9, 2017 at 2:48 PM, Adhemerval Zanella >>> <adhemerval.zanella@linaro.org> wrote: >>>> GCC has moved from using .gnu.linkonce for i386 setup pic register with >>>> minimum current version (as for binutils minimum binutils that support >>>> comdat). This patch replace linkonce usage by comdat. >>> >>> Is this change compatible with older GCC/binutils versions as well as >>> the new ones? >>> >>> zw >>> >> >> I am trying to pinpoint when binutils added comdat support for i686 and >> this [1] is the oldest thread I found. >> >> I also checked with some ancient binutils version and version older than >> 2.16 I see: >> >> test.o: In function `__x86.get_pc_thunk.bx': >> test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx' >> /usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here >> >> Which seems that the can not handle either comdat at all or the mix of >> linkonce and comdat. For binutils 2.16.1 and forward I am getting a >> different issue trying to link a binary with and more recent ctri.o >> (unrecognized relocation (0x2b) in section `.init', which is R_386_GOT32X >> and old binutils won't generate it anyway). >> >> So I think that either unlikely someone will use an older binutils than >> the one used to glibc and even this scenario may fail with some issue >> as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported >> (glibc itself required 2.22). >> >> [1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html >> > > Ping. > Ping.
Ping. On 24/01/2017 18:14, Adhemerval Zanella wrote: > > > On 17/01/2017 08:24, Adhemerval Zanella wrote: >> >> >> On 10/01/2017 12:02, Adhemerval Zanella wrote: >>> >>> >>> On 09/01/2017 18:26, Zack Weinberg wrote: >>>> On Mon, Jan 9, 2017 at 2:48 PM, Adhemerval Zanella >>>> <adhemerval.zanella@linaro.org> wrote: >>>>> GCC has moved from using .gnu.linkonce for i386 setup pic register with >>>>> minimum current version (as for binutils minimum binutils that support >>>>> comdat). This patch replace linkonce usage by comdat. >>>> >>>> Is this change compatible with older GCC/binutils versions as well as >>>> the new ones? >>>> >>>> zw >>>> >>> >>> I am trying to pinpoint when binutils added comdat support for i686 and >>> this [1] is the oldest thread I found. >>> >>> I also checked with some ancient binutils version and version older than >>> 2.16 I see: >>> >>> test.o: In function `__x86.get_pc_thunk.bx': >>> test.o(.text.__x86.get_pc_thunk.bx+0x0): multiple definition of `__x86.get_pc_thunk.bx' >>> /usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/crti.o(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here >>> >>> Which seems that the can not handle either comdat at all or the mix of >>> linkonce and comdat. For binutils 2.16.1 and forward I am getting a >>> different issue trying to link a binary with and more recent ctri.o >>> (unrecognized relocation (0x2b) in section `.init', which is R_386_GOT32X >>> and old binutils won't generate it anyway). >>> >>> So I think that either unlikely someone will use an older binutils than >>> the one used to glibc and even this scenario may fail with some issue >>> as the R_386_GOT32X. Also, 2.16.1 is quite old and not really supported >>> (glibc itself required 2.22). >>> >>> [1] https://gcc.gnu.org/ml/gcc/2004-05/msg00030.html >>> >> >> Ping. >> > > Ping. >
diff --git a/sysdeps/i386/sysdep.h b/sysdeps/i386/sysdep.h index d2b0860..35d65a4 100644 --- a/sysdeps/i386/sysdep.h +++ b/sysdeps/i386/sysdep.h @@ -97,7 +97,7 @@ lose: SYSCALL_PIC_SETUP \ # define SETUP_PIC_REG(reg) \ .ifndef GET_PC_THUNK(reg); \ - .section .gnu.linkonce.t.GET_PC_THUNK(reg),"ax",@progbits; \ + .section .text.GET_PC_THUNK(reg),"axG",@progbits,GET_PC_THUNK(reg),comdat; \ .globl GET_PC_THUNK(reg); \ .hidden GET_PC_THUNK(reg); \ .p2align 4; \ @@ -140,7 +140,8 @@ GET_PC_THUNK(reg): \ # define SETUP_PIC_REG_STR(reg) \ ".ifndef " GET_PC_THUNK_STR (reg) "\n" \ - ".section .gnu.linkonce.t." GET_PC_THUNK_STR (reg) ",\"ax\",@progbits\n" \ + ".section .text." GET_PC_THUNK_STR (reg) ",\"axG\",@progbits," \ + GET_PC_THUNK_STR (reg) ",comdat\n" \ ".globl " GET_PC_THUNK_STR (reg) "\n" \ ".hidden " GET_PC_THUNK_STR (reg) "\n" \ ".p2align 4\n" \