binutils 2.15.91 and 2.16.91: ctors from crtend.o not load on linux cross gcc (__cxa_throw)
Henry Nestler
Henry.Ne@Arcor.de
Thu Jan 12 17:29:00 GMT 2006
* Bug: Cross compile from linux for mingw32 don't init the ctors from
crtend.o! Every 'throw' in a program crashes with a "NULL-Pointer read"
in function __cxa_throw.
* Analysed why it crashed:
>>> Source line:
gcc-3.3.1-20030804-1/libstdc++-v3/libsupc++/eh_throw.cc:64 >>>
header->unexpectedHandler = __unexpected_handler;
<<< snip <<<
"__unexpected_handler" is a macro to variable
"__w32_sharedptr_unexpected", and there was not init. Internal function
"_w32_sharedptr_initialize" was not called before main starts.
This is the standard function tree, started from a section .ctors in
crtend.o:
__reg_frame_ctor
__do_frame_init
__w32_sharedptr_initialize
__register_frame_info
Problem is, that "*crtend.o (.ctors)" in linker script does not include
the function pointer to "__reg_frame_ctor". With other words: The
default linker script from mingw32 not loads contructors from crtend.o.
* Sample source:
>>> cat sample.cc >>>
int main(void)
{
try {
throw "End!";
} catch (...) {
return 1;
}
return 0;
}
<<< end cat <<<
* Build it with linker map
i686-pc-mingw32-g++ -Wl,-M -Wl,--verbose -o sample.exe sample.cc
See the emtpy section .ctors for crtend.o:
>>> old bad map file >>>
0x00406c80 __CTOR_LIST__ = .
0x00406c80 0x4 LONG 0xffffffff
*(EXCLUDE_FILE(*crtend.o) .ctors)
*(.ctor)
*(SORT(.ctors.*))
*crtend.o(.ctors)
0x00406c84 0x4 LONG 0x0
0x00406c88 ___DTOR_LIST__ = .
<<< snip map <<<
* With my patch shows good, for sample:
>>> new good map file >>>
0x00406c80 __CTOR_LIST__ = .
0x00406c80 0x4 LONG 0xffffffff
*(EXCLUDE_FILE(*crtend.o) .ctors)
*(.ctor)
*(SORT(.ctors.*))
*(.ctors)
.ctors 0x00406c84 0x4
/home/hn/CoLinux/mingw32/lib/gcc-lib/i686-pc-mingw32/3.3.1/crtend.o
0x00406c88 0x4 LONG 0x0
0x00406c8c ___DTOR_LIST__ = .
<<< snip map <<<
* Versions:
Build system: i686-pc-linux
Build cross tool chain with:
gcc-Version 3.3.1 (SuSE Linux)
GNU ld version 2.14.90.0.5 20030722 (SuSE Linux)
Used parameters for build Binutils:
./configure --prefix=/home/user/mingw32 --target=i686-pc-mingw32
make
make install
Used parameters for build Compiler:
./configure -v --prefix=/home/user/mingw32 \
--target=i686-pc-mingw32 \
--with-headers=/home/user/mingw32/i686-pc-mingw32/include \
--with-gnu-as \
--with-gnu-ld \
--without-newlib \
--disable-multilib
make LANGUAGES="c c++"
make LANGUAGES="c c++" install
Target system: i686-pc-mingw32
# i686-pc-mingw32-gcc -v
Reading specs from ./../lib/gcc-lib/i686-pc-mingw32/3.3.1/specs
Configured with:
/home/hn/CoLinux/build/co-devel-tmp/gcc-3.3.1-20030804-1/configure -v
--prefix=/home/hn/CoLinux/mingw32 --target=i686-pc-mingw32
--with-headers=/home/hn/CoLinux/mingw32/i686-pc-mingw32/include
--with-gnu-as --with-gnu-ld --without-newlib --disable-multilib
Thread model: single
gcc version 3.3.1 (mingw special 20030804-1)
# i686-pc-mingw32-ld -v
GNU ld version 2.15.91 20040904
# Mingw from source
binutils-2.15.91-20040904-1-src.tar.gz
Same problem if using this versions:
binutils-2.16.91-20050827-1-src.tar.gz
gcc-g++-3.4.4-20050522-1-src.tar.gz
https://sourceforge.net/tracker/index.php?func=detail&aid=1394022&group_id=2435&atid=102435
Have not seen any replay from bug-tracing, so I repeat this as mail now.
My project details can read here:
http://www.henrynestler.com/colinux/patches/devel/throw-readme.txt
--
Henry Nestler
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: binutils-2.15.91-20040904-1-throw.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20060112/ed471544/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: binutils-2.16.91-20050827-1-throw.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20060112/ed471544/attachment-0001.ksh>
More information about the Binutils
mailing list