[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] gcc 4.2.2 patch
Vincent Rivière wrote :
The original binutils patch
didn't relocate the CONSTRUCTORS list at all. Thus, I'm pretty sure that
if a program using CONSTRUCTORS is compiled with GCC 2.95.3 and linked
with binutils 2.13.1, it will crash before main(). In my earlier
patches, I put a workaround in GCC in order to relocate the CONSTRUCTORS
at run time. Recently, I managed to persuade the linker to put the
CONSTRUCTORS into the relocation table as expected. So I removed the
workaround in GCC.
As I'm reviewing the original patch for GCC 2.95.3, I would like to add
some precisions. I hate the inexactitude.
ftp://sparemint.atariforge.net/pub/sparemint/sparemint/cross-mint/src/gcc/gcc-2.95.3-mint-target.patch
1) The GCC workaround (contained in DO_GLOBAL_CTORS_BODY and
DO_GLOBAL_DTORS_BODY, by adding _base + 0x100) was already here in GCC
2.95.3. In my earlier patches, I didn't wrote it, I simply ported this
one. A program made with GCC 2.95.3 and binutils 2.13.1 and using global
constructors works perfectly (unlike what I said before).
2) The original GCC workaround is clever. If the linker forgot to
relocate the constructors (like ld 2.13), it corrects the addresses. If
the linker made its work (latest ld 2.18), it does not fix the
addresses. So a program compiled with GCC 2.95.3 can work with either
binutils 2.13 or 2.18. However, the "clever workaround" is dangerous. It
will fail with binutils 2.13 if the address of a constructor is
greater than (address of text segment * 2). This can be possible for
executables bigger than 140 Ko run on TOS (but safe on ARAnyM).
3) My latest patch for GCC 4.2.2 does not include the workaround
anymore. It is perfectly correct with the latest binutils 2.18. If it is
used with binutils 2.13, it will be correct in most of the cases, except
when linking a C++ program having global variables having a specific
constructor. In that case, it will crash in __main(), called
transparently at the very beginning of main().
There is absolutely nothing mysterious now (about constructors !).
--
Vincent Rivière