This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-ss-20000612: installation failure on hppa2.0n-hp-hpux11.00
- To: gcc at gcc dot gnu dot org
- Subject: Re: gcc-ss-20000612: installation failure on hppa2.0n-hp-hpux11.00
- From: Simon Pamment <spamment at amdocs dot com>
- Date: Sat, 24 Jun 2000 19:19:51 -0500 (CDT)
- Cc: girod at stybba dot ntc dot nokia dot com
- Mailer: Emacs [20.5]
- Reply-To: Simon Pamment <spamment at amdocs dot com>
Hello,
I've been having the same problem as Marc Girod ...
> I am back with my old failure to install egcs on hppa2.0n-hp-hpux11.00
> As evry time since gcc-ss-20000214, the installation fails at building
> the libstdc++ shared library, with the HP linker dumping core on bus
> error.
I attempted to repeat what he did to determine that "tinfo2.o" in
library "libgcc.a" is a problem when creating a shared library. In
addition I think I have managed to distill the problem down further.
Here is what I've found (the first part repeats what he did but I'm
including it here in case anybody else wants to go down the same
path) ...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Here is the output from the "make bootstrap" where the bus error
occurs (after making stages 1 and 2).
... ... ...
... ... ...
/build/gcc/xgcc -B/build/gcc/ -B/usr/local/hppa2.0w-hp-hpux11.00/bin/ \
-g -O2 -fno-implicit-templates -fPIC -shared -o libstdc++.sl \
`cat piclist`
mv tlibstdc++.a.2.10.0 libstdc++.a.2.10.0
true libstdc++.a.2.10.0
collect2: ld terminated with signal 10 [Bus error]
gnumake[2]: *** [libstdc++.sl] Error 1
gnumake[2]: Leaving directory `/build/hppa2.0w-hp-hpux11.00/libstdc++'
gnumake[1]: *** [all-target-libstdc++] Error 2
gnumake[1]: Leaving directory `/build'
gnumake: *** [bootstrap] Error 2
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Tried to build "libstdc++.sl" with each of the object files
mentioned in the "piclist" file in turn. In other words ran the
following command for each object file ($OBJECT_FILE) in "piclist"
/build/gcc/xgcc -B/build/gcc/ -B/usr/local/hppa2.0w-hp-hpux11.00/bin/ \
-g -O2 -fno-implicit-templates -fPIC -shared -o libstdc++.sl \
/build/hppa2.0w-hp-hpux11.00/libstdc++/$OBJECT_FILE
The only object file that caused a problem was "stdexcepti.o"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Running the above command (for OBJECT_FILE=stdexcepti.o) with
the -v flag set showed that the following command was being
executed with the "gcc" library being linked in twice.
/build/gcc/collect2 -z -b -o libstdc++.sl
-L/usr/local/hppa2.0w-hp-hpux11.00/bin -L/build/gcc
-L/usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.00/2.96
-L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib
-L/usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.00/2.96/../../..
/build/hppa2.0w-hp-hpux11.00/libstdc++/pic/stdexcepti.o -lgcc -lgcc
Running this command with the two "-lgcc" entries removed
resulted in a successful build of the library. In other words the
problem was not in "stdexcepti.o" but rather it was in the code
that it pulled in from "libgcc.a".
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Split "libgcc.a" into component files and tried the above
"collect2" command with each of the object files in turn.
/build/gcc/collect2 -v -z -b -o libstdc++.sl
-L/usr/local/hppa2.0w-hp-hpux11.00/bin -L/build/gcc
-L/usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.00/2.96
-L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib
-L/usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.00/2.96/../../..
$OBJECT_FILE
The only object file that caused a problem was "tinfo2.o".
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Performed an iterative process of removing code in "tinfo2.cc"
and checking that the problem still occurred. The following two
commands were used to verify that the compile still worked while
the bus error still occurred (the first command was taken from
the output of the original bootstrap).
/build/gcc/xgcc -v -B/usr/local/hppa2.0w-hp-hpux11.00/bin/
-B/build/gcc/ -isystem /usr/local/hppa2.0w-hp-hpux11.00/include
-O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wno-long-long -O2 -g -O2
-isystem /build/gcc/include -I/build/gcc -I/build/gcc/include
-fPIC -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -g -O2 -I.
-I/build/gcc/../../egcs-20000619/gcc
-I/build/gcc/../../egcs-20000619/gcc/config
-I/build/gcc/../../egcs-20000619/gcc/../include
-c tinfo2.cc
/build/gcc/collect2 -v -z -b -o libstdc++.sl tinfo2.o
This resulted in the following "tinfo2.cc" file.
--------------------------------------------------------
#include <stddef.h>
#include "tinfo.h"
using std::type_info;
extern "C" int
__throw_type_match_rtti_2 (const void *, const void *throw_type_r,
void *, void **)
{
const type_info &throw_type = *(const type_info *)throw_type_r;
if (const __user_type_info *p
= dynamic_cast <const __user_type_info *> (&throw_type))
{
}
return 0;
}
--------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Pulled in the header files and repeated the process. This distilled
the "tinfo2.cc" file down to the following.
--------------------------------------------------------
class type_info {
public:
virtual ~type_info ();
protected:
const char *__name;
explicit type_info (const char *__n): __name (__n) { }
};
struct __user_type_info : public std::type_info {
__user_type_info (const char *n) : type_info (n) {}
};
extern "C" int
__throw_type_match_rtti_2 (const void *, const void *throw_type_r,
void *, void **)
{
const type_info &throw_type = *(const type_info *)throw_type_r;
dynamic_cast <const __user_type_info *> (&throw_type);
return 0;
}
--------------------------------------------------------
After renaming the classes and simplifying the code it reduced to
the following piece of code.
--------------------------------------------------------
class Base
{
public:
virtual ~Base ();
};
struct Derived : public Base
{
};
void
func ()
{
Base *pointer = 0;
dynamic_cast <Derived *> (pointer);
}
--------------------------------------------------------
The following two commands were now sufficient to cause the bus
error.
/build/gcc/xgcc -v -B/build/gcc/ -fPIC -c tinfo2.cc
/usr/bin/ld -v -z -b -o libstdc++.sl tinfo2.o
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Noted that it didn't seem to matter what was added to the Base
class (e.g. member data, other functions whether virtual or
non-virtual) the example still refused to work.
* Noted instead that if the virtual destructor for the Base class
was defined as well as declared then the problem went away. For
example, the following worked.
--------------------------------------------------------
class Base
{
public:
virtual ~Base () {}; <--- Note "{}"
};
--------------------------------------------------------
* Noted that if the destructor was no longer virtual then it would
work as long as there was another function in the class that was
both virtual and defined. For example, the following worked.
--------------------------------------------------------
class Base
{
public:
~Base ();
virtual void rhubarb() {}; <--- Note "virtual" and "defined"
};
--------------------------------------------------------
* Noted that things failed again if an undefined virtual function
was also added to the class. For example, the following didn't
work.
--------------------------------------------------------
class Base
{
public:
~Base ();
virtual void rhubarb() {}; <--- Note "virtual" and "defined"
virtual void asparagus(); <--- Note "virtual" and not "defined"
};
--------------------------------------------------------
* Noted that if the added undefined function was made non-virtual
then things were also fine. The following worked.
--------------------------------------------------------
class Base
{
public:
~Base ();
virtual void rhubarb() {}; <--- Note "virtual" and "defined"
void asparagus(); <--- Note "non-virtual" and not "defined"
};
--------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Compiling the first "Base/Derived" code example from above with
the 2.95.2 compiler proved successful.
Dumping the headers ("objdump -x) for each of the "tinfo2.o"
files (i.e. from the 2.95.2 compiler and the 2.96 compiler)
showed a difference in the symbol table entries.
/* --- 2.95.2 --- */
SYMBOL TABLE:
0000000c *COM* __ti7Derived
40000008 l $DATA$ L$C0002
40000004 l $DATA$ L$C0001
40000000 l $DATA$ L$C0000
00000000 *UND* __ti4Base
00000000 F *UND* __rtti_si <--
00000000 F *UND* __dynamic_cast <-- Note extra "F" flags
00000000 l F $CODE$ __tf7Derived
00000000 F *UND* __tf4Base <--
00000000 g F $CODE$ func__Fv
00000000 l $CODE$ $CODE$
00000000 l $CODE$ $CODE$
/* --- 2.96 --- */
SYMBOL TABLE:
0000000c *COM* __ti7Derived
40000008 l $DATA$ L$C0002
40000004 l $DATA$ L$C0001
40000000 l $DATA$ L$C0000
00000000 *UND* __ti4Base
00000000 *UND* __dynamic_cast_2
00000000 *UND* __rtti_si
00000000 lw F $CODE$ __tf7Derived
00000000 *UND* __tf4Base
00000000 g F $CODE$ func__Fv
00000000 l $CODE$ $CODE$
00000000 l $CODE$ $CODE$
00000000 l $CODE$ gcc2_compiled.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* A hex dump of each of the object files revealed that the symbols
"__dynamic_cast_2", "__rtti_si" and "__tf4Base" had symbol types
coded as ST_DATA (2) in the 2.96 object file and ST_CODE (3) in
the 2.95.2 object file.
--------------------------------------------------------
/* Hex dump of 2.96 generated "tinfo2.o" file */
00000000: 0210 0106 0531 13cc 0000 0000 0000 0000 .....1..........
00000010: 0000 0000 0000 0000 0000 0000 0000 0080 ................
00000020: 0000 0000 0000 0624 0000 0000 0000 0080 .......$........
00000030: 0000 0002 0000 00c8 0000 0007 0000 0000 ................
00000040: 0000 0000 0000 01e0 0000 0074 0000 0080 ...........t....
00000050: 0000 0000 0000 0254 0000 0000 0000 03fc .......T........
00000060: 0000 000d 0000 05d0 0000 0054 0000 0500 ...........T....
00000070: 0000 00d0 0000 03fc 0000 0000 0721 173a .............!.:
00000080: 0000 0004 c000 0800 0000 0000 0000 0000 ................
00000090: 0000 0005 ffff ffff 0000 0000 ffff ffff ................
000000a0: 0000 0000 0000 0010 e000 1000 0000 0001 ................
000000b0: 0000 0005 0000 0002 ffff ffff 0000 0000 ................
000000c0: ffff ffff 0000 0000 0000 0000 5821 1800 ............X!..
000000d0: 0000 0254 0000 0000 0000 0000 0000 0000 ...T............
000000e0: 0000 0008 0000 0020 0000 0000 0000 0000 ....... ........
000000f0: 0000 0000 5820 1000 0000 0254 0000 0000 ....X .....T....
00000100: 0000 0000 0000 0000 0000 0008 0000 0038 ...............8
00000110: 0000 0000 0000 0000 0000 0000 5820 0800 ............X ..
00000120: 0000 0254 0000 0000 0000 0000 0000 0000 ...T............
00000130: 0000 0008 0000 0044 0000 0000 0000 0000 .......D........
00000140: 0000 0000 5821 1800 0000 0254 0000 00c8 ....X!.....T....
00000150: 0000 0000 0000 00c8 0000 0008 0000 0060 ...............`
00000160: 0000 0000 0000 001d 0000 0000 5821 1800 ............X!..
00000170: 0000 031c 0000 00c8 0000 0000 0000 00c8 ................
00000180: 0000 0008 0000 006c 0000 001d 0000 0032 .......l.......2
00000190: 0000 0001 3e28 1800 0000 03e4 0000 0018 ....>(..........
000001a0: 4000 0000 0000 0018 0000 0008 0000 002c @..............,
000001b0: 0000 004f 0000 0005 0000 0001 3e28 5200 ...O........>(R.
000001c0: 0000 0000 0000 0000 4000 0000 0000 0000 ........@.......
000001d0: 0000 0008 0000 0054 ffff ffff 0000 0000 .......T........
000001e0: 0000 0006 2454 4558 5424 0000 0000 0009 ....$TEXT$......
000001f0: 2450 5249 5641 5445 2400 0000 0000 0006 $PRIVATE$.......
00000200: 2443 4f44 4524 0000 0000 0006 2444 4154 $CODE$......$DAT
00000210: 4124 0000 0000 0005 244c 4954 2400 0000 A$......$LIT$...
00000220: 0000 000b 244d 494c 4c49 434f 4445 2400 ....$MILLICODE$.
00000230: 0000 0005 2442 5353 2400 0000 0000 0006 ....$BSS$.......
00000240: 2443 4f44 4524 0000 0000 0006 2443 4f44 $CODE$......$COD
00000250: 4524 0000 6bc2 3fd9 0803 0241 081e 0243 E$..k.?....A...C
00000260: 6fc1 0100 6bd3 3fc1 6864 0030 0813 0244 o...k.?.hd.0...D
00000270: 0c60 1290 0c70 1081 0c61 1298 0c78 1094 .`...p...a...x..
00000280: 8e80 2002 e800 00f2 0c78 1096 0ec0 1095 .. ......x......
00000290: 0c78 1097 0ee0 1094 0e80 1054 d294 1ff0 .x.........T....
000002a0: 0c78 1081 0a81 0a16 2a60 0000 6861 0020 .x......*`..ha.
000002b0: 4874 0020 4a94 0000 6874 0020 4877 0020 Ht. J...ht. Hw.
000002c0: 0ee0 1094 6bd4 3f99 0c78 1081 6bc1 3f91 ....k.?..x..k.?.
000002d0: 0ea8 109a 2a60 0000 6861 0028 4874 0028 ....*`..ha.(Ht.(
000002e0: 4a94 0000 6874 0028 4877 0028 0ee0 1099 J...ht.(Hw.(....
000002f0: 3418 0000 0816 0257 e840 0000 0800 0240 4......W.@.....@
00000300: 0804 0253 4862 3fd9 4864 0030 347e 0080 ...SHb?.Hd.04~..
00000310: 4fc3 3f81 e840 c002 0000 0000 6bc2 3fd9 O.?..@......k.?.
00000320: 0803 0241 081e 0243 6fc1 0100 6bd3 3fc1 ...A...Co...k.?.
00000330: 6864 0040 0813 0244 2a60 0000 0c61 1290 hd.@...D*`...a..
00000340: 0c70 1094 4a94 0000 0c74 1290 0c70 1095 .p..J....t...p..
00000350: 0ea0 1094 8e80 20ba e840 0000 0800 0240 ...... ..@.....@
00000360: 0804 0253 2a60 0000 0c61 1298 0c78 1094 ...S*`...a...x..
00000370: 4a94 0000 0c74 1298 0c78 109a 2a60 0000 J....t...x..*`..
00000380: 6861 0020 4874 0020 4a94 0000 6874 0020 ha. Ht. J...ht.
00000390: 4879 0020 2a60 0000 6861 0028 4874 0028 Hy. *`..ha.(Ht.(
000003a0: 4a94 0000 6874 0028 4878 0028 e840 0000 J...ht.(Hx.(.@..
000003b0: 0800 0240 0804 0253 2a60 0000 6861 0030 ...@...S*`..ha.0
000003c0: 4874 0030 4a94 0000 6874 0030 487c 0030 Ht.0J...ht.0H|.0
000003d0: 4862 3fd9 4864 0040 347e 0080 4fc3 3f81 Hb?.Hd.@4~..O.?.
000003e0: e840 c002 0000 0000 0000 0000 3744 6572 .@..........7Der
000003f0: 6976 6564 0000 0000 0000 0000 0700 0c00 ived............
00000400: 0000 0064 0000 0000 0000 0000 0000 000c ...d............
00000410: 0220 0c00 0000 00c8 0000 0000 0000 0005 . ..............
00000420: 4000 0008 0220 0c00 0000 00b0 0000 0000 @.... ..........
00000430: 0000 0005 4000 0004 0220 0c00 0000 00a4 ....@.... ......
00000440: 0000 0000 0000 0005 4000 0000 0200 0c00 ........@.......
00000450: 0000 0078 0000 0000 0000 0000 0000 0000 ...x............
00000460: 0200 0c00 0000 004c 0000 0000 0000 0000 .......L........
^
+------------------------------------------------------------- "__dynamic_cast_2" (symbol type = 2)
00000470: 0000 0000 0200 0c00 0000 0088 0000 0000 ................
^
+--------------------------------------------------- "__rtti_si" (symbol type = 2)
00000480: 0000 0000 0000 0000 4620 0c01 0000 0028 ........F .....(
00000490: 0000 0000 0000 0004 0000 0003 0200 0c00 ................
^
+------------------------------- "__tf4Base" (symbol type = 2)
000004a0: 0000 0018 0000 0000 0000 0000 0000 0000 ................
000004b0: 0630 0c00 0000 003c 0000 0000 0000 0003 .0.....<........
000004c0: 0000 0003 0320 0c00 0000 0098 0000 0000 ..... ..........
000004d0: 0000 0003 0000 0000 0320 0c00 0000 00bc ......... ......
000004e0: 0000 0000 0000 0004 0000 0000 0320 0c00 ............. ..
000004f0: 0000 0004 0000 0000 0000 0000 0000 0000 ................
00000500: 0000 000e 6763 6332 5f63 6f6d 7069 6c65 ....gcc2_compile
00000510: 642e 0000 0000 0009 5f5f 7466 3442 6173 d.......__tf4Bas
00000520: 6500 0000 0000 000c 5f5f 7466 3744 6572 e.......__tf7Der
00000530: 6976 6564 0000 0000 0000 0008 6675 6e63 ived........func
00000540: 5f5f 4676 0000 0000 0000 0010 5f5f 6479 __Fv........__dy
00000550: 6e61 6d69 635f 6361 7374 5f32 0000 0000 namic_cast_2....
00000560: 0000 000c 5f5f 7469 3744 6572 6976 6564 ....__ti7Derived
00000570: 0000 0000 0000 0009 5f5f 7469 3442 6173 ........__ti4Bas
00000580: 6500 0000 0000 0009 5f5f 7274 7469 5f73 e.......__rtti_s
00000590: 6900 0000 0000 0006 2443 4f44 4524 0000 i.......$CODE$..
000005a0: 0000 0007 4c24 4330 3030 3000 0000 0007 ....L$C0000.....
000005b0: 4c24 4330 3030 3100 0000 0006 2443 4f44 L$C0001.....$COD
000005c0: 4524 0000 0000 0007 4c24 4330 3030 3200 E$......L$C0002.
000005d0: b308 0200 1800 0000 1014 c378 0301 c4d3 ...........x....
000005e0: 06c3 7802 01c4 d304 3405 06b6 00b3 0802 ..x.....4.......
000005f0: 0018 0000 0010 06c3 7800 01c4 d303 3008 ........x.....0.
00000600: 01c3 d401 c4d3 01c3 7801 01c4 d301 c378 ........x......x
00000610: 0401 c4d3 0133 0601 c3d6 01c4 d306 b627 .....3.........'
00000620: 0827 0703 .'..
--------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Generated the assembler (tinfo2.s) for each of the compilers and
found that the 2.95 compiler was generating ".IMPORT" directives
for the above three symbols.
.IMPORT __dynamic_cast_,CODE
.IMPORT __rtti_si,CODE
.IMPORT __tf4Base,CODE
The command to generate the (2.96) assembler output was ...
/build/gcc/xgcc -v -B/build/gcc/ -fPIC -S tinfo2.cc
Edited the 2.96 version of the "tinfo2.s" file to include the
above three ".IMPORT" lines and attempted to create the shared
library again using the following commands.
/build/gcc/xgcc -v -B/build/gcc/ -fPIC -c tinfo2.s
/usr/bin/ld -v -z -b -o libstdc++.sl tinfo2.o
The link was finally SUCCESSFUL !!!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Experimented and found that the minimal change to the assembler
file to make the link work was to add the import line only for
the "__tf4Base" symbol.
This reminded me of the situation described above where if the
Base class had no undefined virtual functions then the problem
disappeared.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Noted the following points about the 2.96 version of "tinfo2.s"
(included below) since at this stage my knowledge of HP-UX
assembler is woefully insufficient.
- The symbols "__dynamic_cast_2", "__rtti_si" and "__tf4Base"
are all only used in "bl" instructions (lines 73, 121 and
143) so why is "__tf4Base" special ?
- The only difference between "__tf4Base" and the other two
symbols is that "__tf4Base" is mentioned in a ".word"
directive on line 16. Does this make it a problem ?
- "__tf7Derived" is the (only) other symbol mentioned in a
".word" directive (line 19) and it is not mentioned in a
".IMPORT" directive either. Is it not a problem because the
"__tf7Derived" is defined as a weakly exported symbol (lines
99-101) ?
--------------------------------------------------------
/* --- 2.96 version of "tinfo2.s" --- */
1 .LEVEL 1.1
2 .SPACE $PRIVATE$
3 .SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
4 .SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
5 .SPACE $TEXT$
6 .SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
7 .SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
8 .IMPORT $global$,DATA
9 .IMPORT $$dyncall,MILLICODE
10 gcc2_compiled.:
11 .SPACE $PRIVATE$
12 .SUBSPA $DATA$
13
14 .align 4
15 L$C0000
16 .word P%__tf4Base
17 .align 4
18 L$C0001
19 .word P%__tf7Derived
20 .SPACE $TEXT$
21 .SUBSPA $CODE$
22
23 .align 4
24 .NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
25 .EXPORT func__Fv,ENTRY,PRIV_LEV=3
26 func__Fv
27 .PROC
28 .CALLINFO FRAME=128,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4
29 .ENTRY
30 stw %r2,-20(%r30)
31 copy %r3,%r1
32 copy %r30,%r3
33 stwm %r1,128(%r30)
34 stw %r19,-32(%r30)
35 stw %r4,24(%r3)
36 copy %r19,%r4
37 stw %r0,8(%r3)
38 ldw 8(%r3),%r1
39 stw %r1,12(%r3)
40 ldw 12(%r3),%r20
41 comib,<>,n 0,%r20,L$0003
42 b,n L$0005
43 L$0003
44 ldw 12(%r3),%r22
45 ldw 0(%r22),%r21
46 ldw 12(%r3),%r23
47 ldw 0(%r23),%r20
48 ldh 0(%r20),%r20
49 extrs %r20,31,16,%r20
50 ldw 12(%r3),%r1
51 addl %r1,%r20,%r22
52 addil LT'L$C0000,%r19
53 stw %r1,16(%r3)
54 ldw 16(%r3),%r20
55 ldw RT'L$C0000(%r20),%r20
56 stw %r20,16(%r3)
57 ldw 16(%r3),%r23
58 ldw 0(%r23),%r20
59 stw %r20,-52(%r30)
60 ldw 12(%r3),%r1
61 stw %r1,-56(%r30)
62 ldw 4(%r21),%r26
63 addil LT'L$C0001,%r19
64 stw %r1,20(%r3)
65 ldw 20(%r3),%r20
66 ldw RT'L$C0001(%r20),%r20
67 stw %r20,20(%r3)
68 ldw 20(%r3),%r23
69 ldw 0(%r23),%r25
70 ldi 0,%r24
71 copy %r22,%r23
72 .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR
73 bl __dynamic_cast_2,%r2
74 nop
75 copy %r4,%r19
76 L$0005
77 ldw -20(%r3),%r2
78 ldw 24(%r3),%r4
79 ldo 64(%r3),%r30
80 ldwm -64(%r30),%r3
81 bv,n %r0(%r2)
82 .EXIT
83 .PROCEND
84 .SPACE $PRIVATE$
85 .SUBSPA $BSS$
86
87 __ti7Derived .comm 12
88 .SPACE $PRIVATE$
89 .SUBSPA $DATA$
90
91 .align 4
92 L$C0002
93 .STRING "7Derived\x00"
94 .SPACE $TEXT$
95 .SUBSPA $CODE$
96
97 .align 4
98 .NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
99 .weak __tf7Derived
100 .EXPORT __tf7Derived,ENTRY,PRIV_LEV=3,RTNVAL=GR
101 __tf7Derived
102 .PROC
103 .CALLINFO FRAME=128,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4
104 .ENTRY
105 stw %r2,-20(%r30)
106 copy %r3,%r1
107 copy %r30,%r3
108 stwm %r1,128(%r30)
109 stw %r19,-32(%r30)
110 stw %r4,32(%r3)
111 copy %r19,%r4
112 addil LT'__ti7Derived,%r19
113 stw %r1,8(%r3)
114 ldw 8(%r3),%r20
115 ldw RT'__ti7Derived(%r20),%r20
116 stw %r20,8(%r3)
117 ldw 8(%r3),%r21
118 ldw 0(%r21),%r20
119 comib,<>,n 0,%r20,L$0007
120 .CALL
121 bl __tf4Base,%r2
122 nop
123 copy %r4,%r19
124 addil LT'__ti7Derived,%r19
125 stw %r1,12(%r3)
126 ldw 12(%r3),%r20
127 ldw RT'__ti7Derived(%r20),%r20
128 stw %r20,12(%r3)
129 ldw 12(%r3),%r26
130 addil LT'L$C0002,%r19
131 stw %r1,16(%r3)
132 ldw 16(%r3),%r20
133 ldw RT'L$C0002(%r20),%r20
134 stw %r20,16(%r3)
135 ldw 16(%r3),%r25
136 addil LT'__ti4Base,%r19
137 stw %r1,20(%r3)
138 ldw 20(%r3),%r20
139 ldw RT'__ti4Base(%r20),%r20
140 stw %r20,20(%r3)
141 ldw 20(%r3),%r24
142 .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR
143 bl __rtti_si,%r2
144 nop
145 copy %r4,%r19
146 L$0007
147 addil LT'__ti7Derived,%r19
148 stw %r1,24(%r3)
149 ldw 24(%r3),%r20
150 ldw RT'__ti7Derived(%r20),%r20
151 stw %r20,24(%r3)
152 ldw 24(%r3),%r28
153 ldw -20(%r3),%r2
154 ldw 32(%r3),%r4
155 ldo 64(%r3),%r30
156 ldwm -64(%r30),%r3
157 bv,n %r0(%r2)
158 .EXIT
159 .PROCEND
--------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* At this point I'm somewhat stuck in being able to characterise
the problem any more precisely. So I'm hoping somebody else (with
a better knowledge of the internals of the compiler) will be able
to identify the problem.
In conclusion I observe the following ...
- the compiler appears to be emitting incorrect assembly code.
- the situation that causes this seems to involve a
dynamic_cast from a pointer to a base class for which there
is an undefined virtual function.