http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
--- Comment #31 from Kai Tietz <ktietz at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #30)
> It looks like a bug in the assembler!
>
> with objdump -d -r crtbegin.o we have wrong code:
>
> f3: 83 ec 04 sub $0x4,%esp
> f6: 85 c0 test %eax,%eax
> f8: ba f0 ff ff ff mov $0xfffffff0,%edx
> f9: dir32 ___deregister_frame_info
> fd: 74 16 je 115 <___gcc_deregister_frame+0x35>
>
>
> but the cygming-crtbegin.s looks correct:
>
> LVL17:
> .loc 1 158 0
> testl %eax, %eax
> .loc 1 162 0
> movl $___deregister_frame_info, %edx
> .loc 1 158 0
> je L27
>
>
> whenever there is a weak definition the reference is actually minus
> the offset of the previous weak definition. Everything is OK if that was
> at offset zero.
>
> test case:
>
> $ cat test.c
> #include <stdio.h>
>
> extern void test() __attribute__((weak));
>
> int main()
> {
> printf("hello\n");
> test();
> return 0;
> }
>
> __attribute__((weak))
> void test()
> {
> printf("weak\n");
> }
>
> $ cat test1.c
> #include <stdio.h>
>
> void test()
> {
> printf("strong\n");
> }
>
>
> $ gcc -o test test.c test1.c
> $ ./test
> hello
> Segmentation fault (core dumped)
Interesting finding. So second issue cooks down to be an binutils bug about
weak. I remember the cause of the change to gcc's crtbegin, and it is pretty
important one (at least for x64). As the implicit zero-relocation doesn't work
on x64 as instructions have +/-2^31 offset in max.
So I would suggest to report this issue on binutils. gcc's bz isn't the right
place to discuss that issue further.
