Re: libgfortran / linker script configuration question
Hi Steve,
Steve Ellcey wrote:
I have a question about the libgfortran configure script. I am trying to
build the fortran language for the mips-mti-elf target (which is built with
newlib) and as part of the configure script for libgfortran it is trying to
check for localtime_r and other functions. These functions exist on my target
but the configure script thinks they don't because the GCC compile and link
done in the configure script doesn't include any linker script options.
So I get:
% install-mips-mti-elf/bin/mips-mti-elf-gcc time.c -o x
/local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld:
warning: cannot find entry symbol __start; defaulting to 00400098
/tmp/ccnihmPO.o: In function `main':
time.c:(.text+0x10): undefined reference to `localtime_r'
collect2: error: ld returned 1 exit status
If I add '-Tmti32.ld' then it compiles cleanly:
% install-mips-mti-elf/bin/mips-mti-elf-gcc -Tmti32.ld time.c -o x
I don't have any problems like this building the C++ library. I guess
it is because that library doesn't use AC_CHECK_FUNCS_ONCE like libgfortran
does.
Well, if I do a grep in libstdc++ that it does not use localtime_r at
all. Thus, it is not surprising that it works there. ;-)
In general, AC_CHECK_FUNCS_ONCE should be a reasonable approach.
(Although, one could argue that using AC_CHECK_FUNCS would be better;
cf.
http://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Generic-Functions.html
)
For the localtime_r issue with newlib,I wonder whether one should do the
same as libjava/configure.ac does:
if test "x${with_newlib}" = "xyes"; then
...
# We assume newlib. This lets us hard-code the functions we know
# we'll have.
...
AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have the 'gmtime_r'
function])
...
Tobias
Re: Crashes inside libgcc_s_dw2-1.dll
> Date: Tue, 21 May 2013 21:19:24 +0300 > From: Eli Zaretskii > CC: gcc@gcc.gnu.org > > > Date: Mon, 20 May 2013 06:37:31 -0700 > > From: Ian Lance Taylor > > Cc: gcc@gcc.gnu.org > > > > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote: > > >> I don't see any obvious bug in the code. Evidently > > >> something is going wrong, but the e-mail messages you linked to don't > > >> provide enough information to know what it is. In particular they > > >> don't show where in __deregister_frame_info_bases the crash is > > >> occurring. > > > > > > I believe that's because the versions of the library which I could > > > find don't have enough debug information. Does someone know where can > > > I find a library with debug info? Failing that, would a disassembly > > > near the address where it crashes be useful? > > > > Normally the library should have debug info. I don't know why it > > doesn't in your case. > > I don't know either. Perhaps the person who prepared the MinGW GCC > package stripped the binaries and the DLLs. GDB clearly says (in > "info shared") that the DLL has no debug info. > > > Yes, a disassembly around the address might possibly help, although > > not if you are correct about where the problem is happening. > > I show the disassembly below. And since the address from which > 'abort' was called didn't make much sense (it pointed to the > instruction _after_ the one that jumped to 'abort'), I also show a > session of stepping through __deregister_frame_info_bases, with > display of the instructions that are being stepped through. I hope > this gives sufficient info to see what is going on. > > My interpretation of what I saw is that the call to 'abort' is indeed > from gcc_assert, because it happens immediately after the return from > __gthread_mutex_unlock, as seen by stepping through the call to > InterlockedDecrement. > > > > Anyway, what we see is not a crash, but a call to 'abort' from Windows > > > runtime. The immediate suspect for that is the line near the end of > > > __deregister_frame_info_bases where there's a call to gcc_assert. > > > Does that make sense? > > > > I don't see why that assert would trigger, no. > > I have a theory about this, based on the following observation: if I > link Emacs with -shared-libgcc, the crashes disappear. > > Looking closer and cygming-crtbegin.c and cygming-crtend.c, I see that > they both test for the shared libgcc being loaded into the process, > but they do that independently. So, if the shared libgcc is loaded > some time after the program start, as a side effect of loading another > DLL (it was libintl in the case in point, which was loaded because > Emacs loaded the GnuTLS library to start a TLS session), crtbegin will > decide that libgcc DLL is not present, while crtend will decide that > it is. Doesn't this asymmetry cause the program to use incompatible > register and deregister code? And wouldn't that in turn cause the > assert to trigger? > > If my theory makes sense, does this mean that loading _any_ DLL that > depends on libgcc as a shared library _requires_ the program to be > linked with -shared-libgcc? If this is indeed so, and by design > rather than by accident, then it would be an unfortunate restriction, > since a program can be built on one machine and then the binary > installed and used on another, with different builds of the same > DLLs. Like in this case. Ping! Any further comments? Is my analysis correct? Does the program need to be linked with -shared-libgcc? TIA
Re: Crashes inside libgcc_s_dw2-1.dll
On Tue, Jun 4, 2013 at 9:39 AM, Eli Zaretskii wrote: >> Date: Tue, 21 May 2013 21:19:24 +0300 >> From: Eli Zaretskii >> CC: gcc@gcc.gnu.org >> >> > Date: Mon, 20 May 2013 06:37:31 -0700 >> > From: Ian Lance Taylor >> > Cc: gcc@gcc.gnu.org >> > >> > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote: >> > >> I don't see any obvious bug in the code. Evidently >> > >> something is going wrong, but the e-mail messages you linked to don't >> > >> provide enough information to know what it is. In particular they >> > >> don't show where in __deregister_frame_info_bases the crash is >> > >> occurring. >> > > >> > > I believe that's because the versions of the library which I could >> > > find don't have enough debug information. Does someone know where can >> > > I find a library with debug info? Failing that, would a disassembly >> > > near the address where it crashes be useful? >> > >> > Normally the library should have debug info. I don't know why it >> > doesn't in your case. >> >> I don't know either. Perhaps the person who prepared the MinGW GCC >> package stripped the binaries and the DLLs. GDB clearly says (in >> "info shared") that the DLL has no debug info. >> >> > Yes, a disassembly around the address might possibly help, although >> > not if you are correct about where the problem is happening. >> >> I show the disassembly below. And since the address from which >> 'abort' was called didn't make much sense (it pointed to the >> instruction _after_ the one that jumped to 'abort'), I also show a >> session of stepping through __deregister_frame_info_bases, with >> display of the instructions that are being stepped through. I hope >> this gives sufficient info to see what is going on. >> >> My interpretation of what I saw is that the call to 'abort' is indeed >> from gcc_assert, because it happens immediately after the return from >> __gthread_mutex_unlock, as seen by stepping through the call to >> InterlockedDecrement. >> >> > > Anyway, what we see is not a crash, but a call to 'abort' from Windows >> > > runtime. The immediate suspect for that is the line near the end of >> > > __deregister_frame_info_bases where there's a call to gcc_assert. >> > > Does that make sense? >> > >> > I don't see why that assert would trigger, no. >> >> I have a theory about this, based on the following observation: if I >> link Emacs with -shared-libgcc, the crashes disappear. >> >> Looking closer and cygming-crtbegin.c and cygming-crtend.c, I see that >> they both test for the shared libgcc being loaded into the process, >> but they do that independently. So, if the shared libgcc is loaded >> some time after the program start, as a side effect of loading another >> DLL (it was libintl in the case in point, which was loaded because >> Emacs loaded the GnuTLS library to start a TLS session), crtbegin will >> decide that libgcc DLL is not present, while crtend will decide that >> it is. Doesn't this asymmetry cause the program to use incompatible >> register and deregister code? And wouldn't that in turn cause the >> assert to trigger? >> >> If my theory makes sense, does this mean that loading _any_ DLL that >> depends on libgcc as a shared library _requires_ the program to be >> linked with -shared-libgcc? If this is indeed so, and by design >> rather than by accident, then it would be an unfortunate restriction, >> since a program can be built on one machine and then the binary >> installed and used on another, with different builds of the same >> DLLs. Like in this case. > > Ping! Any further comments? Is my analysis correct? Does the > program need to be linked with -shared-libgcc? I know very little about how these things work on Windows. However, it is fairly likely that full support for throwing exceptions across shared libraries on Windows does require using a shared libgcc. And as far as I know that should be the default. That is how things used to work on GNU/Linux, before the linker's --eh-frame-hdr option was introduced. Ian
Re: Crashes inside libgcc_s_dw2-1.dll
> Date: Tue, 4 Jun 2013 09:45:10 -0700 > From: Ian Lance Taylor > Cc: gcc@gcc.gnu.org > > I know very little about how these things work on Windows. However, > it is fairly likely that full support for throwing exceptions across > shared libraries on Windows does require using a shared libgcc. Indeed, throwing exceptions across DLLs requires a shared libgcc. But that wasn't the issue. The issue was why does the shared libgcc abort at program exit, if it is loaded dynamically as a side effect of loading another shared library (in this case, libintl) some time during the run of the main program? To recap: Emacs loads GnuTLS when the user starts a TLS session, and that in turn loads libintl and the shared libgcc. Then, when Emacs exits, there's an abort inside libgcc, where there's some assertion. The details are in the message I posted on May 21. My question was: is this expected? Does a program that loads the shared libgcc in mid-flight need to be linked with -shared-libgcc flag? Or is this some bug in libgcc? Thanks.
Re: Crashes inside libgcc_s_dw2-1.dll
On Tue, Jun 4, 2013 at 10:13 AM, Eli Zaretskii wrote: > My question was: is this expected? Does a program that loads the > shared libgcc in mid-flight need to be linked with -shared-libgcc > flag? Or is this some bug in libgcc? I don't think anybody knows the answer to that. I doubt the behaviour was planned. Ian
