On Mon, Aug 29, 2011 at 06:38:11PM +0200, Bernd Schmidt wrote:
> On 08/29/11 18:37, H.J. Lu wrote:
> > On Mon, Aug 29, 2011 at 9:36 AM, H.J. Lu wrote:
>
> >> Doesn't Google have a patch to change it to __x86.get_pc_thunk.bx?
> >>
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02422.html
>
On 08/29/11 18:37, H.J. Lu wrote:
> On Mon, Aug 29, 2011 at 9:36 AM, H.J. Lu wrote:
>> Doesn't Google have a patch to change it to __x86.get_pc_thunk.bx?
>>
>
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02422.html
Cool. I guess I'll approve and commit this version, unless someone sees
a reas
On Mon, Aug 29, 2011 at 9:36 AM, H.J. Lu wrote:
> On Mon, Aug 29, 2011 at 9:11 AM, Bernd Schmidt
> wrote:
>> We currently generate
>>
>> __i686.get_pc_thunk.bx:
>> movl (%esp), %ebx
>> ret
>> in PIC binaries. This can cause problems if the assembly output ends up
>> in a .S file
On Mon, Aug 29, 2011 at 9:11 AM, Bernd Schmidt wrote:
> We currently generate
>
> __i686.get_pc_thunk.bx:
> movl (%esp), %ebx
> ret
> in PIC binaries. This can cause problems if the assembly output ends up
> in a .S file which is then compiled again: __i686 is a predefined macro
>
We currently generate
__i686.get_pc_thunk.bx:
movl(%esp), %ebx
ret
in PIC binaries. This can cause problems if the assembly output ends up
in a .S file which is then compiled again: __i686 is a predefined macro
and expands to "1". This happens in glibc when compiling csu/crti.S