https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #54 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- Grepping for IN in the execution traces and then running a diff reveals interesting things: IN: __libc_start_main IN: __libc_start_main IN: _dl_discover_osversion -IN: uname -IN: uname +IN: __uname +IN: __uname IN: _dl_discover_osversion IN: _dl_discover_osversion IN: _dl_discover_osversion @@ -53,18 +53,18 @@ IN: __udivsi3 IN: __udivsi3 IN: __libc_setup_tls -IN: sbrk -IN: sbrk +IN: __sbrk +IN: __sbrk IN: __brk IN: __brk IN: __brk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk -IN: sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk +IN: __sbrk [...] @@ -445,12 +446,13 @@ IN: _gfortran_set_options IN: _gfortran_set_options IN: _gfortran_set_options -IN: bsd_signal -IN: bsd_signal +IN: ssignal +IN: ssignal IN: __bsd_signal.part.0 IN: __bsd_signal.part.0 -IN: __sigaction -IN: __sigaction +IN: sigaction +IN: sigaction +IN: sigaction IN: __libc_sigaction IN: __libc_sigaction IN: memcpy It seems that the test case is calling a different C library version with and without the patch; especially, it is using the bsd_signal function without the patch and ssignal with it. This is strange, to say the least, and points towards a basic problem with the OS, or the emulator... I am a bit at a loss of how to proceed.
