s390x (64bit) compile?/link?/load? problem..
Brian Horton
bhh_mail@mail.com
Thu Aug 1 21:46:00 GMT 2002
Not sure if this is a compiler problem, link problem or run-time load
problem, but I'll post here. I've run out of ideas on where to look for
the solution to this, so I'm hoping that someone else can see something
that I'm not, or point me to something that will help.
I'm building some 64bit user-side code for running on s390x (SuSE's
SLES7
64bit with the 2.4.17 kernel; gcc is 2.95.3; ld is 2.11.90.0.27; glibc
is 2.2.4).
Specifically I'm building a pam module.
Short description of the problem - my code core dumps, and it appears to
be because it jumps to an invalid address instead of jumping to libc's
open(). The address LOOKS like a 31bit address instead, so I'm not sure
if I have a build (gcc/ld) problem or a problem with the load on the
system.
Here's the core dump:
aushat50:~ # gdb passwd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "s390x-suse-linux"...(no debugging symbols
found)...
(gdb) break open
Breakpoint 1 at 0x80002388
(gdb) run
Starting program: /usr/bin/passwd
.
.
(no debugging symbols found)...
Breakpoint 1, 0x10000014a8c in open () from /lib/ld64.so.1
(gdb) x/s $gpr2
0x8000b290: "/lib64/security/pam_pdos.so.1"
(gdb) where
#0 0x10000014a8c in open () from /lib/ld64.so.1
#1 0x10000008122 in open_verify () from /lib/ld64.so.1
#2 0x10000009212 in _dl_map_object () from /lib/ld64.so.1
#3 0x100001aed58 in dl_open_worker () from /lib64/libc.so.6
#4 0x1000000f206 in _dl_catch_error () from /lib/ld64.so.1
#5 0x100001af292 in _dl_open () from /lib64/libc.so.6
#6 0x1000007fe1a in dlopen_doit () from /lib64/libdl.so.2
#7 0x1000000f206 in _dl_catch_error () from /lib/ld64.so.1
#8 0x10000080302 in _dlerror_run () from /lib64/libdl.so.2
#9 0x1000007fe6a in dlopen@@GLIBC_2.2 () from /lib64/libdl.so.2
#10 0x10000073906 in _pam_add_handler () from /lib64/libpam.so.0
#11 0x10000073268 in _pam_parse_conf_file () from /lib64/libpam.so.0
#12 0x1000007342c in _pam_init_handlers () from /lib64/libpam.so.0
#13 0x10000072504 in pam_start () from /lib64/libpam.so.0
#14 0x800063a0 in __libc_start_main ()
(gdb) c
Continuing.
(no debugging symbols found)...
Program received signal SIGILL, Illegal instruction.
0x1008000238a in ?? ()
(gdb) where
#0 0x1008000238a in ?? ()
#1 0x1000027a334 in ioctl_call () from /lib64/security/pam_pdos.so.1
#2 0x1000027a42c in kosseal_call () from /lib64/security/pam_pdos.so.1
#3 0x1000027a294 in kosseal_getLoginData () from
/lib64/security/pam_pdos.so.1
#4 0x10000271dd4 in lpm_sl_init () from /lib64/security/pam_pdos.so.1
#5 0x1000000f4be in call_init () from /lib/ld64.so.1
#6 0x1000000f67e in _dl_init () from /lib/ld64.so.1
#7 0x100001af152 in dl_open_worker () from /lib64/libc.so.6
#8 0x1000000f206 in _dl_catch_error () from /lib/ld64.so.1
#9 0x100001af292 in _dl_open () from /lib64/libc.so.6
#10 0x1000007fe1a in dlopen_doit () from /lib64/libdl.so.2
#11 0x1000000f206 in _dl_catch_error () from /lib/ld64.so.1
#12 0x10000080302 in _dlerror_run () from /lib64/libdl.so.2
#13 0x1000007fe6a in dlopen@@GLIBC_2.2 () from /lib64/libdl.so.2
#14 0x10000073906 in _pam_add_handler () from /lib64/libpam.so.0
#15 0x10000073268 in _pam_parse_conf_file () from /lib64/libpam.so.0
#16 0x1000007342c in _pam_init_handlers () from /lib64/libpam.so.0
#17 0x10000072504 in pam_start () from /lib64/libpam.so.0
#18 0x800063a0 in __libc_start_main ()
that is where ioctl is trying to call open:
(gdb) print ioctl_call
$1 = {<text variable, no debug info>} 0x1000027a2f4 <ioctl_call>
(gdb) x/30i ioctl_call
0x1000027a2f4 <ioctl_call>: EB 6F F0 30 00 24 stmg
%r6,%r15,48(%r15)
0x1000027a2fa <ioctl_call+6>: C0 D0 00 00 31 2C larl
%r13,0x10000280552
<sccsid+296>
0x1000027a300 <ioctl_call+12>: B9 04 00 1F lgr %r1,%r15
0x1000027a304 <ioctl_call+16>: A7 FB FF 10 aghi %r15,-240
0x1000027a308 <ioctl_call+20>: E3 10 F0 00 00 24 stg %r1,0(%r15)
0x1000027a30e <ioctl_call+26>: E3 30 F0 D8 00 24 stg %r3,216(%r15)
0x1000027a314 <ioctl_call+32>: B9 04 00 72 lgr %r7,%r2
0x1000027a318 <ioctl_call+36>: E3 40 F0 E0 00 24 stg %r4,224(%r15)
0x1000027a31e <ioctl_call+42>: E3 50 F0 E8 00 24 stg %r5,232(%r15)
0x1000027a324 <ioctl_call+48>: C0 20 00 00 31 10 larl
%r2,0x10000280544
<sccsid+282>
0x1000027a32a <ioctl_call+54>: A7 39 00 02 lghi %r3,2
0x1000027a32e <ioctl_call+58>: C0 E5 3F EC 40 2D brasl
%r14,0x10080002388
0x1000027a334 <ioctl_call+64>: 18 C2 lr %r12,%r2
obj_dump shows:
aushat50:~ # objdump -Rrd /lib64/security/pam_pdos.so.1|more
/lib64/security/pam_pdos.so.1: file format elf64-s390
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
.
.
000000000001d330 R_390_PC32DBL open+0x0000000000000002
.
.
000000000001d2f4 <ioctl_call>:
1d2f4: eb 6f f0 30 00 24 stmg %r6,%r15,48(%r15)
1d2fa: c0 d0 00 00 31 2c larl %r13,23552
<sccsid+0x128>
1d300: b9 04 00 1f lgr %r1,%r15
1d304: a7 fb ff 10 aghi %r15,-240
1d308: e3 10 f0 00 00 24 stg %r1,0(%r15)
1d30e: e3 30 f0 d8 00 24 stg %r3,216(%r15)
1d314: b9 04 00 72 lgr %r7,%r2
1d318: e3 40 f0 e0 00 24 stg %r4,224(%r15)
1d31e: e3 50 f0 e8 00 24 stg %r5,232(%r15)
1d324: c0 20 00 00 31 10 larl %r2,23544 <sccsid+0x11a>
1d32a: a7 39 00 02 lghi %r3,2
1d32e: c0 e5 00 00 00 00 brasl %r14,1d32e
<ioctl_call+0x3a>
1d334: 18 c2 lr %r12,%r2
and obj_dump of the source .o shows:
# objdump -dr kosseal.o|more
kosseal.o: file format elf64-s390
Disassembly of section .text:
0000000000000000 <ioctl_call>:
0: eb 6f f0 30 00 24 stmg %r6,%r15,48(%r15)
6: c0 d0 00 00 00 00 larl %r13,6 <ioctl_call+0x6>
8: R_390_PC32DBL .rodata+0x10
c: b9 04 00 1f lgr %r1,%r15
10: a7 fb ff 10 aghi %r15,-240
14: e3 10 f0 00 00 24 stg %r1,0(%r15)
1a: e3 30 f0 d8 00 24 stg %r3,216(%r15)
20: b9 04 00 72 lgr %r7,%r2
24: e3 40 f0 e0 00 24 stg %r4,224(%r15)
2a: e3 50 f0 e8 00 24 stg %r5,232(%r15)
30: c0 20 00 00 00 00 larl %r2,30 <ioctl_call+0x30>
32: R_390_PC32DBL .rodata+0x2
36: a7 39 00 02 lghi %r3,2
3a: c0 e5 00 00 00 00 brasl %r14,3a <ioctl_call+0x3a>
3c: R_390_PC32DBL open+0x2
40: 18 c2 lr %r12,%r2
The source code starts off:
int
ioctl_call(
int subcall,
pal_scall_parm_t p1,
pal_scall_parm_t p2,
pal_scall_parm_t p3,
pal_scall_parm_t p4,
pal_scall_parm_t p5)
{
int fd = 0, rc, arg_rc;
if (( fd = open(FULL_DEVICE_NAME, O_RDWR)) == -1) {
if ((errno != EPERM) && (errno != EACCES))
errno = ENOSYS;
return(-1);
}
.
.
So whats going on? The address that we're jumping to (0x1008000238a)
looks to me like an 31bit address - but how did that get there? Is it
because of the R_390_PC32DBL label? NONE of the other .so's in
/lib64/security have that for any
symbols; for open I found:
aushat50:/lib64/security # objdump -Rrd *so|grep " open"
0000000000003518 R_390_JMP_SLOT openlog
.
0000000000003f38 R_390_JMP_SLOT open
.
And they just have open -- not open+0x00000002 - why?
What else should I look at? I've found with building with the gcc/ld
that
ship with SuSE SLES7, as well as a cross compiler we built with the IBM
patches (though, the 07/25/02 gcc and bin-utils patches aren't in there;
I'll try them later this week, although I don't think that these will
fix
my problem).
Any help or pointers?
thx.bri.
More information about the Binutils
mailing list