Bug 60830 - [4.9 Regression] ICE on bootstrapping on cygwin
Summary: [4.9 Regression] ICE on bootstrapping on cygwin
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.9.0
: P1 normal
Target Milestone: 4.9.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 61003 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-04-13 10:27 UTC by Denis Excoffier
Modified: 2014-07-13 17:03 UTC (History)
5 users (show)

See Also:
Host: i686-pc-cygwin
Target: i686-pc-cygwin
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed: 2014-04-14 00:00:00


Attachments
top level config.log (6.75 KB, text/plain)
2014-04-14 09:05 UTC, Denis Excoffier
Details
i686-pc-cygwin/libgcc/config.log (2.76 KB, text/plain)
2014-04-14 09:06 UTC, Denis Excoffier
Details
gdb session catching signal SIGABRT (1.59 KB, text/plain)
2014-04-14 14:43 UTC, Denis Excoffier
Details
gdb session stepping until the end (2.93 KB, text/plain)
2014-04-15 09:34 UTC, Denis Excoffier
Details
discover __DTOR_LIST__ (2.30 KB, text/plain)
2014-04-15 16:20 UTC, Denis Excoffier
Details
bootstrap works at least under i686 (437 bytes, patch)
2014-04-21 16:31 UTC, Denis Excoffier
Details | Diff
another possible workaround (541 bytes, patch)
2014-04-21 20:39 UTC, Bernd Edlinger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Excoffier 2014-04-13 10:27:51 UTC
Installed gcc-4.9.0-RC-20140411 on darwin (Mavericks) with no problem. But:

On Cygwin 1.7.29-2 (+ latests patches), platform=i686-pc-cygwin (Windows XP SP3, 32 bits), bootstrap stops with:

xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure: error: in `/tmp/lcl/tmp/gcc/obj/i686-pc-cygwin/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2


Indeed, inside /tmp/lcl/tmp/obj/gcc:
% echo "int main() { return 0; }" > foo.c
% cc1 -quiet -o foo.c foo.c
foo.c:1:1: internal compiler error: Aborted
 int main() { return 0; }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
%

The foo.o seems ok. After some investigation, it seems that cc1 receives an unexpected SIGABRT signal, after the end of main(), and strace confirms the kill:
% strace -o /tmp/1 cc1 -quiet -o foo.o foo.c
(same messages as above)
% cat /tmp/1
...
 344 4823227 [main] cc1 3768 close: 0 = close(3)
2019 4825246 [main] cc1 3768 set_signal_mask: setmask 0, newmask FFFEFEDK, mask_bits 0
  23 4825269 [main] cc1 3768 kill0: kill (3768, 6)
  22 4825291 [main] cc1 3768 sig_send: sendsig 0x784, pid 3768, signal 6, its_me 1
...
%


On the other hand, if foo.c is erroneous, all seems ok:
% echo "it main() { return 0; }" > foo.c
foo.c:1:1: error: unknown type name 'it'
 it main() { return 0; }
 ^
foo.c:1: confused by earlier errors, bailing out
%

I don't know what to do next.
Comment 1 Denis Excoffier 2014-04-13 11:05:07 UTC
Typos:
- 1st cc1 command should read "cc1 -quiet -o foo.o foo.c" instead of "cc1 -quiet -o foo.c foo.c"
- the newmask in strace output is FFFEFEDF and not FFFEFEDK
- the cc1 command is missing when foo.c is erroneous:
cc1 -quiet -o foo.o foo.c

Also, tke kill (xxxx, 6) is also present when foo.c is erroneous.
Comment 2 Mikael Pettersson 2014-04-13 12:33:35 UTC
I'm getting a different error bootstrapping the 4.9.0 RC on Cygwin:

checking for C compiler default output file name... 
configure: error: in `/home/mikpe/objdir/i686-pc-cygwin/libgcc':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:14037: recipe for target 'configure-stage2-target-libgcc' failed
make[2]: *** [configure-stage2-target-libgcc] Error 77
make[2]: Leaving directory '/home/mikpe/objdir'
Makefile:16771: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/home/mikpe/objdir'
Makefile:16974: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

Inspecting i686-pc-cygwin/libgcc/config.log shows a number of failed attempts to run gcc/xgcc:

xgcc: error: unrecognized command line option '-isystem'
xgcc: error: unrecognized command line option '-v'

which eventually causes configure to give up.

This is with cygwin-1.7.28 (32-bit), Windows 7 (64-bit), Core-i7.
Comment 3 Richard Biener 2014-04-14 08:44:10 UTC
Can you provide a full backtrace?  This looks like a library we link to calling abort () (gcc itself doesn't do that without printing some pretty message).
Comment 4 Richard Biener 2014-04-14 08:45:03 UTC
Btw, the usual suspicious one is gmp which in older versions used to abort ()
on "impossible" CPU kinds in its CPU detection code (at least trips on qemu
default configs for example)
Comment 5 Denis Excoffier 2014-04-14 09:05:37 UTC
Created attachment 32591 [details]
top level config.log
Comment 6 Denis Excoffier 2014-04-14 09:06:42 UTC
Created attachment 32592 [details]
i686-pc-cygwin/libgcc/config.log
Comment 7 Denis Excoffier 2014-04-14 09:11:07 UTC
Here are the config.log found at top level and the config.log at
i686-pc-cygwin/libgcc level (see attachments).

What do you need more specifically?

I have to say that i use gmp-6.0.0a, mpfr-3.1.2 (without patches), and mpc-1.0.2, all of them untarred in the source tree. All of them work well for building GCC 4.8.2.
Comment 8 Jakub Jelinek 2014-04-14 14:15:57 UTC
I guess for start, it would be nice to see backtrace from the debugger about where the segfault and/or abort happened.
Comment 9 Denis Excoffier 2014-04-14 14:42:31 UTC
(In reply to Jakub Jelinek from comment #8)
> I guess for start, it would be nice to see backtrace from the debugger about
> where the segfault and/or abort happened.

See attachment 3 [details].
Comment 10 Denis Excoffier 2014-04-14 14:43:42 UTC
Created attachment 32595 [details]
gdb session catching signal SIGABRT
Comment 11 Kai Tietz 2014-04-14 17:06:17 UTC
(In reply to Denis Excoffier from comment #10)
> Created attachment 32595 [details]
> gdb session catching signal SIGABRT

Thanks for the debug-log.  Could you please attach the backtrace starting from the fancy_abort call? (That what you see after up 7).
The issue here is that deregister is called without any register object (ob).  Therefore is got NULL.
Comment 12 Kai Tietz 2014-04-14 18:54:35 UTC
(In reply to Denis Excoffier from comment #10)
> Created attachment 32595 [details]
> gdb session catching signal SIGABRT

Some comments here:
- it might be helpful to install proper debug-information (cygwin1.dbg doesn't match cygwin1.dll)
- to ease debugging it might be helpful to translate gcc without optimizations
- As side-note: is there by any chance -std=c++11 active on built?

The issue seems to be a global-destructor.  The issue might be that
a) A library doesn't register .eh_frame.  Nevertheless tries to destruct it
b) There is tried to destruct it more then once.  (Maybe try to set a break-point on that function to find if it get called more then once)
c) Issue might be to have mixed static/shared version.  This could lead to register/deregister-issues too.

In general it would be of interest to learn what destructors (by whom) are present in the list called by do_global_dtors (&__DTOR_LIST__)
Comment 13 Denis Excoffier 2014-04-15 09:34:57 UTC
Created attachment 32600 [details]
gdb session stepping until the end
Comment 14 Denis Excoffier 2014-04-15 09:35:42 UTC
I'm now using plain cygwin-1.7.29-2, the cygwin1.dbg now matches with cygwin1.dll. I've alto tried to recompile without -O2. I'm not so familiar with gdb, i've produced a session where i break at __call_exitprocs (in cygwin1.dll), that shows that the destructors are not called more than once. But i now obtain 2 SEGV. Hope this helps. See attachment 32600 [details].
Comment 15 Kai Tietz 2014-04-15 09:59:39 UTC
(In reply to Denis Excoffier from comment #14)
> I'm now using plain cygwin-1.7.29-2, the cygwin1.dbg now matches with
> cygwin1.dll. I've alto tried to recompile without -O2. I'm not so familiar
> with gdb, i've produced a session where i break at __call_exitprocs (in
> cygwin1.dll), that shows that the destructors are not called more than once.
> But i now obtain 2 SEGV. Hope this helps. See attachment 32600 [details].

Thanks, the second SIGSEGV is the "Second Chance exception".  Nothing to wonder here.  There seems to be no handler catching the SIGSEGV's first chance exception.
Comment 16 Richard Biener 2014-04-15 10:04:19 UTC
Hum.  This looks like a cygwin issue to me?  Do earlier cygwin versions work ok?

I only see x86_64-cygwin testresults posted semi-regularly from Tim Prince but
no i686-cygwin ones (which is the platform listed in secondary targets).

Adding the rest of cygwin maintainers to CC.
Comment 17 Kai Tietz 2014-04-15 10:31:05 UTC
Just as side-note, I tried to reproduce your reported issue and did a personal build of cygwin's gcc.  It worked fine in stage2.  I couldn't reproduce the reported ICE on stage2.  Which brings me to the question if you are using additional patches/fixes, etc
Comment 18 Kai Tietz 2014-04-15 12:19:03 UTC
Another side-note.  You should specify option '--disable-multilib'.  this is pretty essential as cygwin doesn't support it right now.
Comment 19 Denis Excoffier 2014-04-15 16:20:29 UTC
Created attachment 32602 [details]
discover __DTOR_LIST__
Comment 20 Denis Excoffier 2014-04-15 16:31:45 UTC
(In reply to Kai Tietz from comment #12)
> In general it would be of interest
> to learn what destructors (by whom) are present in the list called by
> do_global_dtors (&__DTOR_LIST__)

I've rebuilt everything, under plain cygwin-1.7.29-2, with BOOT_CFLAGS=-g instead of "-g -O2". I carefully didn't rebuilt anything after the failure in i686-pc-cygwin/libgcc like before and cc1 seems to work, BUT xgcc still does not work (with the same symptoms).

xgcc --version (or -dumpspecs) shows something on stdout, but when piped into wc, there is no output... Strange.

The __DTOR_LIST__ contains a single item: deregister_frame_dtor (see attachment 32602 [details]).

Also the specs file is not built (is built empty, see in attachment the -dumpspecs parameter), this is probably the cause of the "xgcc: error: unrecognized command line option 'X'" (with X=--version, or -mtune=generic, or -march=pentiumpro) when the -B/tmp/lcl/tmp/gcc/obj/gcc/ option is used.
Comment 21 Denis Excoffier 2014-04-15 16:50:45 UTC
(In reply to Kai Tietz from comment #17)
> Just as side-note, I tried to reproduce your reported issue and did a
> personal build of cygwin's gcc.  It worked fine in stage2.  I couldn't
> reproduce the reported ICE on stage2.  Which brings me to the question if
> you are using additional patches/fixes, etc
Did you use 32bits? Did you use a recent cygwin version? There has been some movement recently (2014-03-28) in dtors.cc, although i believe that only 64bits is impacted.
Comment 22 Kai Tietz 2014-04-15 17:55:40 UTC
(In reply to Denis Excoffier from comment #21)
> (In reply to Kai Tietz from comment #17)
> > Just as side-note, I tried to reproduce your reported issue and did a
> > personal build of cygwin's gcc.  It worked fine in stage2.  I couldn't
> > reproduce the reported ICE on stage2.  Which brings me to the question if
> > you are using additional patches/fixes, etc
> Did you use 32bits? Did you use a recent cygwin version? There has been some
> movement recently (2014-03-28) in dtors.cc, although i believe that only
> 64bits is impacted.

I built recent gcc 4.9 on my pre-installed cygwin 32-bit (as you did too, as logs have shown).  Only difference I made was to disable multilib.  And this you should do too.

Additionally I built x64 version on my cygwin64 environment too.
So from my point of view it isn't a gcc issue.  As both targets are bootstrapping without issue for me.

So, it might be an issue with recent cygwin, I can test that too.  I will continue on that tomorrow as it takes me pretty long to built it native. Nevetheless I doubt that I will find different results for gcc.  And if it is really dependent on cygwin-dll version, then it seems to me indeed like a cygwin-bug
Comment 23 Bernd Edlinger 2014-04-15 21:32:11 UTC
FYI: I have 32-bit cygwin 1.7.28-2/XP SP2 here, and the following configuration
builds successfully:

../gcc-4.9.0-RC-20140411/configure --prefix=/<full-path-to-install> --enable-languages=c,c++

gmp etc. in-tree with: contrib/download_prerequisites
Comment 24 Denis Excoffier 2014-04-16 07:38:30 UTC
Well, i suppose it can be RESOLVED_INVALID.

Last night i built successfully with 1.7.28-2. I was using some non-standard configuration for gmp and as soon as this kludge was removed, gcc built perfectly (once...). I have to confirm this with a few other builds, latest cygwin version etc. I'll keep you informed.

Hence, my fault. However, i am curious to know how Mikael (see comment #2) was able to obtain the exact very same symptoms (to be honest: nearly). Please could you provide details?
Comment 25 Kai Tietz 2014-04-16 12:10:27 UTC
So I close this bug.  Don't hesitate to answer Denis' question.
Comment 26 Denis Excoffier 2014-04-18 12:36:56 UTC
After more investigation, it seems that the culprit can be
--disable-sjlj-exceptions. Since the beginning (last Sunday), each time i use it on the command line, the build fails and each time i don't use it, the build succeeds.

Please would you mind trying again a cygwin build, but with --disable-sjlj-exceptions this time. Especially for those where the build succeeded. For Mikael (see comment #2), it is more than probable that he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody except by me.
Comment 27 Bernd Edlinger 2014-04-18 19:37:50 UTC
(In reply to Denis Excoffier from comment #26)
> After more investigation, it seems that the culprit can be
> --disable-sjlj-exceptions. Since the beginning (last Sunday), each time i
> use it on the command line, the build fails and each time i don't use it,
> the build succeeds.
> Please would you mind trying again a cygwin build, but
> with --disable-sjlj-exceptions this time. Especially for those where the
> build succeeded. For Mikael (see comment #2), it is more than probable that
> he used --disable-sjlj-exceptions instead of my gmp kludges known by nobody
> except by me.

Yes, adding --disable-sjlj-exceptions makes the build fail:

mkdir -p -- i686-pc-cygwin/libgcc
Checking multilib configuration for libgcc...
Configuring stage 2 in i686-pc-cygwin/libgcc
configure: creating cache ./config.cache
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
xgcc: error: unrecognized command line option '-isystem'
xgcc: error: unrecognized command line option '-isystem'
xgcc: error: unrecognized command line option '-mtune=generic'
xgcc: error: unrecognized command line option '-march=pentiumpro'
checking for i686-pc-cygwin-ar... ar
checking for i686-pc-cygwin-lipo... lipo
checking for i686-pc-cygwin-nm... /home/ED/gnu/gcc-build/./gcc/nm
checking for i686-pc-cygwin-ranlib... ranlib
checking for i686-pc-cygwin-strip... strip
checking whether ln -s works... yes
checking for i686-pc-cygwin-gcc... /home/ED/gnu/gcc-build/./gcc/xgcc -B/home/ED/gnu/gcc-build/./gcc/ -B/home/ed/gnu/install/i686-pc-cygwin/bin/ -B/home/ed/gnu/install/i686-pc-cygwin/lib/ -isystem /home/ed/gnu/install/i686-pc-cygwin/include -isystem /home/ed/gnu/install/i686-pc-cygwin/sys-include
checking for C compiler default output file name...
configure: error: in `/home/ED/gnu/gcc-build/i686-pc-cygwin/libgcc':
configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:17788: recipe for target 'configure-stage2-target-libgcc' failed
make[2]: *** [configure-stage2-target-libgcc] Error 77
make[2]: Leaving directory '/home/ED/gnu/gcc-build'
Makefile:20606: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/home/ED/gnu/gcc-build'
Makefile:897: recipe for target 'all' failed
make: *** [all] Error 2
Comment 28 Mikael Pettersson 2014-04-19 13:04:10 UTC
My attempted bootstraps of 4.8.2 on Cygwin failed due to three reasons:

1. I had --disable-sjlj-exceptions, which worked with previous releases.  Dropping that and adding --disable-multilib (based on Kai's comment, not sure it's needed in a purely 32-bit setting) made things work again.

[Cygwin's own gcc-4.8.2 is built with --disable-sjlj-exceptions however.  I don't know why it works for them but not for us.]

2. I tried to build with make -j4, that caused strange linkage errors.  Dropping that and doing a non-parallell make made things work again.

3. The Ada bootstrap always failed with:

/home/mikpe/objdir/./gcc/xgcc -B/home/mikpe/objdir/./gcc/ -B/opt/local/gcc-4.8/i686-pc-cygwin/bin/ -B/opt/local/gcc-4.8/i686-pc-cygwin/lib/ -isystem /opt/local/gcc-4.8/i686-pc-cygwin/include -isystem /opt/local/gcc-4.8/i686-pc-cygwin/sys-include    -c -g -O2   -W -Wall -gnatpg -nostdinc   g-sercom.adb -o g-sercom.o
g-sercom.adb:40:12: warning: no entities of "System.OS_Constants" are referenced
g-sercom.adb:46:04: warning: no entities of "OSC" are referenced
g-sercom.adb:209:42: "DTR_CONTROL_ENABLE" not declared in "OS_Constants"
g-sercom.adb:211:42: "RTS_CONTROL_ENABLE" not declared in "OS_Constants"
../gcc-interface/Makefile:310: recipe for target 'g-sercom.o' failed
make[4]: *** [g-sercom.o] Error 1

This appears to be a known bug, I found a report of it in gcc-help, 
http://gcc.gnu.org/ml/gcc-help/2012-10/msg00003.html, and a patch in
http://sourceforge.net/p/cygwin-ports/gcc/ci/master/tree/4.8-gcc-ada-DTR.patch.

(Ada on Cygwin uses mingw's g-sercom.adb which references those two symbols, but s-oscons-tmplt.c only defines those symbols for mingw, not for Cygwin.  As far as I can tell this issue is still present in 4.9 and 4.10.)

With all three adjustments I was finally able to bootstrap 4.8.2 on Cygwin.
Comment 29 Bernd Edlinger 2014-04-20 19:08:52 UTC
Hmm, that is really strange.

the crash happens in __gcc_deregister_frame.
just break at this function and step.
The first call is GetModuleHandle (LIBGCC_SONAME) which
returns NULL, so the weak default __deregister_frame_info
is used. BUT the address is wrong by 0x10.

00401170 <___gcc_deregister_frame>:
  401170:       55                      push   %ebp
  401171:       89 e5                   mov    %esp,%ebp
  401173:       83 ec 18                sub    $0x18,%esp
  401176:       c7 04 24 20 71 47 00    movl   $0x477120,(%esp)
  40117d:       ff 15 50 b4 4c 00       call   *0x4cb450
  401183:       83 ec 04                sub    $0x4,%esp
  401186:       85 c0                   test   %eax,%eax
  401188:       ba 10 25 47 00          mov    $0x472510,%edx
  40118d:       74 16                   je     4011a5 <___gcc_deregister_frame+0x35>
  40118f:       c7 44 24 04 67 71 47    movl   $0x477167,0x4(%esp)
  401196:       00
  401197:       89 04 24                mov    %eax,(%esp)
  40119a:       ff 15 54 b4 4c 00       call   *0x4cb454
  4011a0:       83 ec 08                sub    $0x8,%esp
  4011a3:       89 c2                   mov    %eax,%edx
  4011a5:       85 d2                   test   %edx,%edx
  4011a7:       74 09                   je     4011b2 <___gcc_deregister_frame+0x42>
  4011a9:       c7 04 24 38 b0 4b 00    movl   $0x4bb038,(%esp)
  4011b0:       ff d2                   call   *%edx

=> this call goes to 0x472510 instead of 0x472520.
....

  4724ff:       e8 fc 01 00 00          call   472700 <_free>
  472504:       8b 44 24 1c             mov    0x1c(%esp),%eax
  472508:       83 c4 28                add    $0x28,%esp
  47250b:       5b                      pop    %ebx
  47250c:       c3                      ret
  47250d:       89 d0                   mov    %edx,%eax
  47250f:       ba e4 ac 4c 00          mov    $0x4cace4,%edx
  472514:       eb a6                   jmp    4724bc <___deregister_frame_info_bases+0x6c>
  472516:       8d 76 00                lea    0x0(%esi),%esi
  472519:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

00472520 <___deregister_frame_info>:
  472520:       e9 2b ff ff ff          jmp    472450 <___deregister_frame_info_bases>
  472525:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
  472529:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi
Comment 30 Bernd Edlinger 2014-04-21 14:02:42 UTC
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)
Comment 31 Kai Tietz 2014-04-21 14:52:40 UTC
(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.
Comment 32 Bernd Edlinger 2014-04-21 16:27:10 UTC
OK,

opened a binutils-bug at: https://sourceware.org/bugzilla/show_bug.cgi?id=16858
Comment 33 Denis Excoffier 2014-04-21 16:31:25 UTC
Created attachment 32651 [details]
bootstrap works at least under i686
Comment 34 Denis Excoffier 2014-04-21 16:35:34 UTC
The patch under attachment 32651 [details] seems to make bootstrapping behave better, at least for i686.
Comment 35 Bernd Edlinger 2014-04-21 16:50:06 UTC
would not using --disable-sjlj-excaptions cause any problems,
maybe a unwanted ABI-Change?
Comment 36 Denis Excoffier 2014-04-21 17:01:44 UTC
(In reply to Bernd Edlinger from comment #35)
> would not using --disable-sjlj-excaptions cause any problems,
> maybe a unwanted ABI-Change?
I don't know really. Cygwin people usually build gcc using --disable-sjlj-exceptions and the /usr/bin/cyggcc_s-1.dll is never very far. Without --disable-sjlj-exceptions, you get a ${prefix}/bin/cyggcc_s-sjlj-1.dll, and i believe that cyggcc_s-1.dll and cyggcc_s-sjlj-1.dll are not supposed to live together very well.
Comment 37 Bernd Edlinger 2014-04-21 17:18:49 UTC
(In reply to Denis Excoffier from comment #36)
> (In reply to Bernd Edlinger from comment #35)
>> would not using --disable-sjlj-excaptions cause any problems,
>> maybe a unwanted ABI-Change?
> I don't know really. Cygwin people usually build gcc using
> --disable-sjlj-exceptions and the /usr/bin/cyggcc_s-1.dll is never very far.
> Without --disable-sjlj-exceptions, you get a
> ${prefix}/bin/cyggcc_s-sjlj-1.dll, and i believe that cyggcc_s-1.dll and
> cyggcc_s-sjlj-1.dll are not supposed to live together very well.

That sounds in deed like a problem.

Regarding your patch:
I believe the reason for the gas-bug is that more than one weak default
definitions in one .o file and calling them from ths same compilation unit caused the bug.

Maybe it would work, if you move all (maybe but one) default definitions from
cygming-crtbegin.c to cygming-crtend.c, leaving just the forward declarations.
Comment 38 Denis Excoffier 2014-04-21 17:40:18 UTC
(In reply to Bernd Edlinger from comment #37)

> Regarding your patch:
I've tested it and it works (as far as i can tell): the bootstrap has gone until the end (installation in ${prefix}). objdump -d crtbegin.o contains ba 00 00 00 00 instead of ba f0 ff ff ff, and the .weak... objects at the beginning of crtbegin.o are gone. More than that, i've built (with this GCC 4.9) several usual distributions (for the moment: sed, patch, diffutils, bzip2, make, gawk, xz, many others to come of course).
Comment 39 Kai Tietz 2014-04-21 17:52:35 UTC
Well, the patch might work-a-round issue.  Nevertheless it just paperbags the real issue existing in binutils.
Additionally the patch would break x64 version of cygwin.  At least that was the reason why we introduced it.
Comment 40 Bernd Edlinger 2014-04-21 20:39:56 UTC
Created attachment 32652 [details]
another possible workaround

This is what I am bootstrapping right now.
Looks good so far, it just reached stage3.
Comment 41 Bernd Edlinger 2014-04-21 20:48:40 UTC
(In reply to Kai Tietz from comment #39)
> Well, the patch might work-a-round issue.  Nevertheless it just paperbags
> the real issue existing in binutils.
> Additionally the patch would break x64
> version of cygwin.  At least that was the reason why we introduced it.

Kai, this issue is also present in binutils-2.22, and probably very old.

So it really deserves a work-around on our side.

As far as I understood from your messages on gcc-patches, the
PE-Format is not able to handle weak externals without any definition.
But it is not a requirement, that the weak definition is in the
same file, where it is used.  So this patch just moves the
weak definitions to another file. The only file I could think of
is cygming-crtend.c, because crtbegin.o and crtend.o are always
used in pairs.

What do you think, will this work for x64 too?

Bernd.
Comment 42 Kai Tietz 2014-04-22 07:24:43 UTC
Second variant of the patch looks ok to me, if bootstrap works for 32-bit and 64-bit cygwin.
Post patch to ML for gcc trunk, and if no further issues are present we can merge patch to 4.9.1
Comment 43 Bernd Edlinger 2014-04-22 07:29:41 UTC
(In reply to Kai Tietz from comment #42)
> Second variant of the patch looks ok to me, if bootstrap works for 32-bit
> and 64-bit cygwin.
> Post patch to ML for gcc trunk, and if no further issues are present we can
> merge patch to 4.9.1

Boot-Strap works for 32 bit.
Could you please try 64 bit for me,
as I don't have access to that configuration?
Comment 44 Denis Excoffier 2014-04-22 07:38:17 UTC
(In reply to Kai Tietz from comment #42)
> Second variant of the patch looks ok to me, if bootstrap works for 32-bit
> and 64-bit cygwin.
Post patch to ML for gcc trunk, and if no further issues
> are present we can merge patch to 4.9.1
I have no access to a 64bit cygwin, but if the patch works there, shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1? After all, the bootstrap (with --disable-sjlj-exceptions) fails and this cannot be worse with the patch. Also there is no impact on other (non-cygwin) configurations.
Comment 45 Denis Excoffier 2014-04-22 13:50:25 UTC
(In reply to Denis Excoffier from comment #44)
> shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1?
No because 4.9.0 is out.
Comment 46 Mikael Pettersson 2014-04-27 14:10:32 UTC
Using a binutils with the proposed patch for binutils' PR 16858 I can now bootstrap gcc-4.8.2 with --disable-sjlj-exceptions on Cygwin.
Comment 47 Kai Tietz 2014-04-30 14:23:31 UTC
*** Bug 61003 has been marked as a duplicate of this bug. ***
Comment 48 Fanael 2014-05-02 17:36:21 UTC
Is revision 209946 an attempt to fix this?
Comment 49 Bernd Edlinger 2014-05-02 19:50:01 UTC
(In reply to Fanael from comment #48)
> Is revision 209946 an attempt to fix this?

Yes. It is supposed to fix the cygwin-32 build with
--disable-sjlj-exceptions
Comment 50 Denis Excoffier 2014-07-13 10:34:21 UTC
gcc-4.9.1-RC-20140710 bootstraps perfectly. Thank you.