[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: g++-cris - multiple call to virtual thunk across shared library causes SEGV

a month ago I posted this to the list, no responses so far.
the segfault still occurs with the latest cris-tools/devboard82
has anyone verified?


-----Ursprüngliche Nachricht-----
Von: owner-dev-etrax@xxxxxxx.com">mailto:owner-dev-etrax@xxxxxxx.com] Im
Auftrag von Tobias Schütte
Gesendet: Sonntag, 21. Dezember 2003 16:35
An: dev-etrax@xxxxxxx.com
Betreff: g++-cris - multiple call to virtual thunk across shared library
causes SEGV


at present I'm porting three huge shared c++ libraries with a lot of
virtual classes to devboard82. g++-cris (3.2.1 Axis release R54/1.54
debian package) compiles the code without any errors and without
suspicious warnings, nice work since release 1.25 :-)

most classes of the three libraries work fine, but some calls to virtual
member functions causes a user programm to segfault, cuz execution jumps
into the middle of nowhere. first of all, I thought that the libraries
were too big for the devboard but after debugging with gdb-cris and
analysing the member functions that causes the segfault, I noticed that
a sequence of calls to virtual thunks is the problem.

I reduced the "howto-repeat-code" to a c++ program using two libraries.
most of the code never gets executed, it is only dummy code to create
the right symbol table with weak symbols to set up a sequence of calls
to virtual thunks, as shown here:

cris-objdump -R liblib1.so | grep Default1
00003ee4 R_CRIS_32         _ZN13ReaderDefault11resetErrorsEv
00003f14 R_CRIS_32         _ZThn12_N13ReaderDefault11resetErrorsEv
(virtual thunk)
000041e4 R_CRIS_JUMP_SLOT  _ZN13ReaderDefault11resetErrorsEv

cris-objdump -R liblib2.so | grep resetErrorCount
00003a48 R_CRIS_32         _ZN17ReaderWrapperImpl15resetErrorCountEv
00003a5c R_CRIS_32
_ZThn4_N17ReaderWrapperImpl15resetErrorCountEv (virtual thunk)
00003d34 R_CRIS_JUMP_SLOT  _ZN17ReaderWrapperImpl15resetErrorCountEv

I did not invest more time to find the origin of the problem because my
knowledge relative cris asm is insufficient to be able to judge which
code exactly causes the problem, perhaps glibc´s elf/dl-*.c files play
thereby a role.

grap an gzipd tar from here: http://www.edvwl.de/dload/libbug.tar.gz