Package: binutils
Version: 2.18.1~cvs20080103-7
Severity: normal
While attempting to run Firefox 4.0 on a DEC Alpha, after finally
succeeding in building it from sources, the program fails with a SIGILL.
Upon further investigation it appears the problem is due to an incorrect
relocation during the construction of the shared library libxul.so.
The following is an exerpt from an objdump of the object file resulting
from the compilation of the C++ file
mozilla-2.0/xpcom/base/nsCycleCollector.cpp showing the generated code
in which the relocation problem occurs:
0000000000000c6c <_ZN16nsCycleCollectorC1Ev>:
c6c: 00 00 bb 27 ldah gp,0(t12)
c6c: GPDISP .text+0x4
c70: 00 00 bd 23 lda gp,0(gp)
c74: f0 ff de 23 lda sp,-16(sp)
c78: 00 00 3d a4 ldq t0,0(gp)
c78: ELF_LITERAL
_ZTV29nsCycleCollectionXPCOMRuntime+0x10
c7c: 08 00 3e b5 stq s0,8(sp)
c80: 09 04 f0 47 mov a0,s0
c84: 00 00 5e b7 stq ra,0(sp)
c88: a8 00 29 22 lda a1,168(s0)
c8c: 78 00 29 b4 stq t0,120(s0)
c90: c0 00 10 22 lda a0,192(a0)
c94: 01 00 3f 20 lda t0,1
c98: 00 00 e9 b3 stl zero,0(s0)
c9c: 10 00 29 b0 stl t0,16(s0)
ca0: 04 00 e9 b3 stl zero,4(s0)
ca4: 0c 00 e9 b3 stl zero,12(s0)
ca8: 80 00 e9 b7 stq zero,128(s0)
cac: 88 00 e9 b7 stq zero,136(s0)
cb0: 90 00 e9 b7 stq zero,144(s0)
cb4: 98 00 e9 b7 stq zero,152(s0)
cb8: a0 00 e9 b3 stl zero,160(s0)
cbc: a8 00 e9 b3 stl zero,168(s0)
cc0: b0 00 e9 b7 stq zero,176(s0)
cc4: b8 00 e9 b3 stl zero,184(s0)
cc8: 00 00 7d a7 ldq t12,0(gp)
cc8: ELF_LITERAL
_ZN14nsPurpleBufferC1ER22nsCycleCollectorParams
ccc: 00 40 5b 6b jsr ra,(t12),cd0
<_ZN16nsCycleCollectorC1Ev+0x64>
ccc: LITUSE .text+0x3
ccc: HINT
_ZN14nsPurpleBufferC1ER22nsCycleCollectorParams
cd0: 00 00 ba 27 ldah gp,0(ra)
cd0: GPDISP .text+0x4
cd4: 00 00 bd 23 lda gp,0(gp)
cd8: 20 00 09 22 lda a0,32(s0)
cdc: 00 00 7d a7 ldq t12,0(gp)
cdc: ELF_LITERAL memset
ce0: 11 04 ff 47 clr a1
ce4: 58 00 5f 22 lda a2,88
ce8: 00 40 5b 6b jsr ra,(t12),cec
<_ZN16nsCycleCollectorC1Ev+0x80>
ce8: LITUSE .text+0x3
ce8: HINT memset
cec: 00 00 ba 27 ldah gp,0(ra)
cec: GPDISP .text+0x10
cf0: 78 00 29 20 lda t0,120(s0)
cf4: 28 00 29 b4 stq t0,40(s0)
cf8: 00 00 5e a7 ldq ra,0(sp)
cfc: 00 00 bd 23 lda gp,0(gp)
d00: 08 00 3e a5 ldq s0,8(sp)
d04: 10 00 de 23 lda sp,16(sp)
d08: 01 80 fa 6b ret
Of concern is the code from offset cc8: through offset cd4: (a call to
another C++ function) which results in the ultimate failure upon
execution of the jsr instruction at offset ce8: (a call to the function
memset). The following is an exerpt of an objdump of the corresponding
code in the shared library libxul.so showing the final relocated
function:
00000000016993a0 <_ZN16nsCycleCollectorC1Ev>:
16993a0: cc 00 bb 27 ldah gp,204(t12)
16993a4: 58 1e bd 23 lda gp,7768(gp)
16993a8: f0 ff de 23 lda sp,-16(sp)
16993ac: 28 f2 3d a4 ldq t0,-3544(gp)
16993b0: 08 00 3e b5 stq s0,8(sp)
16993b4: 09 04 f0 47 mov a0,s0
16993b8: 00 00 5e b7 stq ra,0(sp)
16993bc: a8 00 29 22 lda a1,168(s0)
16993c0: 78 00 29 b4 stq t0,120(s0)
16993c4: c0 00 10 22 lda a0,192(a0)
16993c8: 01 00 3f 20 lda t0,1
16993cc: 00 00 e9 b3 stl zero,0(s0)
16993d0: 10 00 29 b0 stl t0,16(s0)
16993d4: 04 00 e9 b3 stl zero,4(s0)
16993d8: 0c 00 e9 b3 stl zero,12(s0)
16993dc: 80 00 e9 b7 stq zero,128(s0)
16993e0: 88 00 e9 b7 stq zero,136(s0)
16993e4: 90 00 e9 b7 stq zero,144(s0)
16993e8: 98 00 e9 b7 stq zero,152(s0)
16993ec: a0 00 e9 b3 stl zero,160(s0)
16993f0: a8 00 e9 b3 stl zero,168(s0)
16993f4: b0 00 e9 b7 stq zero,176(s0)
16993f8: b8 00 e9 b3 stl zero,184(s0)
16993fc: 00 00 fe 2f unop
1699400: a9 06 40 d3 bsr ra,169aea8
<_ZN14nsPurpleBufferC1ER22nsCycleCollectorParams+0x8>
1699404: 00 00 fe 2f unop
1699408: 00 00 fe 2f unop
169940c: 20 00 09 22 lda a0,32(s0)
1699410: 38 9f 7d a7 ldq t12,-24776(gp)
1699414: 11 04 ff 47 clr a1
1699418: 58 00 5f 22 lda a2,88
169941c: 00 40 5b 6b jsr ra,(t12),1699420
<_ZN16nsCycleCollectorC1Ev+0x80>
1699420: cc 00 ba 27 ldah gp,204(ra)
1699424: 78 00 29 20 lda t0,120(s0)
1699428: 28 00 29 b4 stq t0,40(s0)
169942c: 00 00 5e a7 ldq ra,0(sp)
1699430: d8 1d bd 23 lda gp,7640(gp)
1699434: 08 00 3e a5 ldq s0,8(sp)
1699438: 10 00 de 23 lda sp,16(sp)
169943c: 01 80 fa 6b ret
Again, of concern is the code from offset 16993fc: through offset
1699408: because, upon execution, the gp register gets altered in the
function called by the bsr instruction at offset 1699400:. The following
two instructions, which in the original code restored the value of the
gp, have been converted to no-ops. Thus, when the instruction at offset
1699410: loads register t12, it does so with an incorrect value. When
the jsr instruction at offset 169941c: is executed it jumps to a
location containing the illegal instruction reported by the SIGILL
exception.
The following is a record of a debug session for the program showing the
failure:
../run-mozilla.sh -g ./firefox-bin
MOZILLA_FIVE_HOME=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
LD_LIBRARY_PATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/plugins:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
DISPLAY=:0.0
DYLD_LIBRARY_PATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
LIBRARY_PATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/components:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
SHLIB_PATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
LIBPATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin:/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
ADDON_PATH=/home/browser/firefox/mozilla-2.0/obj/browser/dist/bin
MOZ_PROGRAM=./firefox-bin
MOZ_TOOLKIT=
moz_debug=1
moz_debugger=
moz_debugger_args=
/usr/bin/gdb --args ./firefox-bin
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "alpha-linux-gnu"...
(gdb) b nsCycleCollector::nsCycleCollector()
Function "nsCycleCollector::nsCycleCollector()" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Breakpoint 1 (nsCycleCollector::nsCycleCollector()) pending.
(gdb) run
Starting program:
/mnt/work/browser/kits/firefox/mozilla-2.0/obj/browser/dist/bin/firefox-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x20003cbef30 (LWP 2879)]
[New Thread 0x2000517f240 (LWP 2882)]
[Switching to Thread 0x20003cbef30 (LWP 2879)]
Breakpoint 1, 0x000002000170b3ac in nsCycleCollector::nsCycleCollector ()
from /home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/libxul.so
Current language: auto; currently asm
(gdb) disas
Dump of assembler code for function _ZN16nsCycleCollectorC1Ev:
0x000002000170b3a0 <_ZN16nsCycleCollectorC1Ev+0>: ldah gp,204(t12)
0x000002000170b3a4 <_ZN16nsCycleCollectorC1Ev+4>: lda gp,7768(gp)
0x000002000170b3a8 <_ZN16nsCycleCollectorC1Ev+8>: lda sp,-16(sp)
0x000002000170b3ac <_ZN16nsCycleCollectorC1Ev+12>: ldq t0,-3544(gp)
0x000002000170b3b0 <_ZN16nsCycleCollectorC1Ev+16>: stq s0,8(sp)
0x000002000170b3b4 <_ZN16nsCycleCollectorC1Ev+20>: mov a0,s0
0x000002000170b3b8 <_ZN16nsCycleCollectorC1Ev+24>: stq ra,0(sp)
0x000002000170b3bc <_ZN16nsCycleCollectorC1Ev+28>: lda a1,168(s0)
0x000002000170b3c0 <_ZN16nsCycleCollectorC1Ev+32>: stq t0,120(s0)
0x000002000170b3c4 <_ZN16nsCycleCollectorC1Ev+36>: lda a0,192(a0)
0x000002000170b3c8 <_ZN16nsCycleCollectorC1Ev+40>: lda t0,1
0x000002000170b3cc <_ZN16nsCycleCollectorC1Ev+44>: stl zero,0(s0)
0x000002000170b3d0 <_ZN16nsCycleCollectorC1Ev+48>: stl t0,16(s0)
0x000002000170b3d4 <_ZN16nsCycleCollectorC1Ev+52>: stl zero,4(s0)
0x000002000170b3d8 <_ZN16nsCycleCollectorC1Ev+56>: stl zero,12(s0)
0x000002000170b3dc <_ZN16nsCycleCollectorC1Ev+60>: stq zero,128(s0)
0x000002000170b3e0 <_ZN16nsCycleCollectorC1Ev+64>: stq zero,136(s0)
0x000002000170b3e4 <_ZN16nsCycleCollectorC1Ev+68>: stq zero,144(s0)
0x000002000170b3e8 <_ZN16nsCycleCollectorC1Ev+72>: stq zero,152(s0)
0x000002000170b3ec <_ZN16nsCycleCollectorC1Ev+76>: stl zero,160(s0)
0x000002000170b3f0 <_ZN16nsCycleCollectorC1Ev+80>: stl zero,168(s0)
0x000002000170b3f4 <_ZN16nsCycleCollectorC1Ev+84>: stq zero,176(s0)
0x000002000170b3f8 <_ZN16nsCycleCollectorC1Ev+88>: stl zero,184(s0)
0x000002000170b3fc <_ZN16nsCycleCollectorC1Ev+92>: unop
0x000002000170b400 <_ZN16nsCycleCollectorC1Ev+96>: bsr
ra,0x2000170cea8 <_ZN14nsPurpleBufferC1ER22nsCycleCollectorParams+8>
0x000002000170b404 <_ZN16nsCycleCollectorC1Ev+100>: unop
0x000002000170b408 <_ZN16nsCycleCollectorC1Ev+104>: unop
0x000002000170b40c <_ZN16nsCycleCollectorC1Ev+108>: lda a0,32(s0)
0x000002000170b410 <_ZN16nsCycleCollectorC1Ev+112>: ldq t12,-24776(gp)
0x000002000170b414 <_ZN16nsCycleCollectorC1Ev+116>: clr a1
0x000002000170b418 <_ZN16nsCycleCollectorC1Ev+120>: lda a2,88
0x000002000170b41c <_ZN16nsCycleCollectorC1Ev+124>: jsr
ra,(t12),0x2000170b420 <_ZN16nsCycleCollectorC1Ev+128>
0x000002000170b420 <_ZN16nsCycleCollectorC1Ev+128>: ldah gp,204(ra)
0x000002000170b424 <_ZN16nsCycleCollectorC1Ev+132>: lda t0,120(s0)
0x000002000170b428 <_ZN16nsCycleCollectorC1Ev+136>: stq t0,40(s0)
0x000002000170b42c <_ZN16nsCycleCollectorC1Ev+140>: ldq ra,0(sp)
0x000002000170b430 <_ZN16nsCycleCollectorC1Ev+144>: lda gp,7640(gp)
0x000002000170b434 <_ZN16nsCycleCollectorC1Ev+148>: ldq s0,8(sp)
0x000002000170b438 <_ZN16nsCycleCollectorC1Ev+152>: lda sp,16(sp)
0x000002000170b43c <_ZN16nsCycleCollectorC1Ev+156>: ret
End of assembler dump.
(gdb) info reg gp
gp 0x200023cd1f8 0x200023cd1f8
(gdb) x/g $gp-24776
0x200023c7130: 0x000002000315f880
(gdb) print memset
$1 = {<text variable, no debug info>} 0x2000315f880 <memset>
(gdb) nexti 21
0x000002000170b400 in nsCycleCollector::nsCycleCollector ()
from /home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/libxul.so
(gdb) x/i $pc
0x2000170b400 <_ZN16nsCycleCollectorC1Ev+96>:
bsr ra,0x2000170cea8 <_ZN14nsPurpleBufferC1ER22nsCycleCollectorParams+8>
(gdb) info reg gp
gp 0x200023cd1f8 0x200023cd1f8
(gdb) nexti
0x000002000170b404 in nsCycleCollector::nsCycleCollector ()
from /home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/libxul.so
(gdb) x/i $pc
0x2000170b404 <_ZN16nsCycleCollectorC1Ev+100>: unop
(gdb) info reg gp
gp 0x2000239b000 0x2000239b000
(gdb) nexti 4
0x000002000170b414 in nsCycleCollector::nsCycleCollector ()
from /home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/libxul.so
(gdb) x/i $pc
0x2000170b414 <_ZN16nsCycleCollectorC1Ev+116>: clr a1
(gdb) info reg gp t12
gp 0x2000239b000 0x2000239b000
t12 0x20002167198 2199058280856
(gdb) x/i $t12
0x20002167198 <_ZTV12nsURIChecker+328>: call_pal 0x72b804
(gdb) nexti 3
Program received signal SIGILL, Illegal instruction.
0x000002000216719c in vtable for nsURIChecker ()
from /home/browser/firefox/mozilla-2.0/obj/browser/dist/bin/libxul.so
(gdb) quit
The program is running. Exit anyway? (y or n)
I am a C programmer, not a C++ programmer, and I do not spend much time
these days working with assembly language. I do not know if it is common
to assume the code for a C++ function does not alter the gp register.
Judging from the code shown in the object file dump above, this does not
appear to be the assumption made by the compiler when generating the
original code because the code sets the gp upon entry and restores this
new value after the jsr instruction at offset ccc:. Furthermore, the
code does not save the value of the gp register at the time of the call
and does not restore it prior to return.
Clearly the compiler assumes a local GOT is to be used, but the linker
has arranged to use a single shared GOT when the shared library was
built. Note in the debug session above, the function is entered after
the first two instructions so the gp register is unaltered. This is
consistent with an assumption the gp register is set once and remains
unaltered during the remainder of the execution. Thus, the two
instructions following the bsr instruction are removed (i.e., converted
to no-ops) because it is assumed they are not needed, and, if retained,
would alter the gp register in violation of this assumption. Yet the C++
function called by the bsr instruction clearly violates this assumption
itself.
I don't know what's going on here. I'll leave further diagnosis to those
who do. If I can be of further help just ask.
-- System Information:
Debian Release: 5.0.8
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: alpha
Kernel: Linux 2.6.26-2-alpha-generic
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages binutils depends on:
ii libc6.1 2.7-18lenny7 GNU C Library: Shared libraries
binutils recommends no packages.
Versions of packages binutils suggests:
ii binutils-doc 2.18.1~cvs20080103-7 Documentation for the GNU assemble
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
