On 11/09/2011 08:21 PM, Neale Ferguson wrote: Hi,
your cmdlines to build the shared lib look correct. The assembler code shows that the code has been built correctly with -fPIC. However, the relocations in the .o and .so files look like non-pic code. With -fPIC it should be R_390_PLT32DBL in the .o and there has to be a R_390_JMP_SLOT relocation in the .so. The R_390_PC32DBL is not sufficient to reach the symbol. So it looks like AS ignores the "@PLT" modifier completely. But your system would not work at all if this really would be the case. What distro are you using? I wasn't able to reproduce it on the system I have access to. Bye, -Andreas- > I’m having a senior moment. I have a program, one of the things it does is > call gettimeofday(), I compiled with –fPIC then I put into a shared library > which I built using gcc –shared. When a program that is linked against this > shared library runs and invokes the program in question it craps out calling > gettimeofday() branching somewhere unexpected (i.e. Not within libc.so which > is what I would have expected). > > I’ve verified that the code generated is correct: > > lgr %r1,%r11 > aghi %r1,168 > lgr %r2,%r1 > lghi %r3,0 > brasl %r14,gettimeofday@PLT > lg %r1,168(%r11) > Used readelf on the objet to see what it thinks about that symbol: > > 00000000012a 062900000013 R_390_PC32DBL 0000000000000000 gettimeofday + 2 > 000000003736 062900000013 R_390_PC32DBL 0000000000000000 gettimeofday + 2 > 1577: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND gettimeofday > > Used it again on the shared library: > > 00000000c572 005c00000013 R_390_PC32DBL 0000000000000000 gettimeofday + 2 > 00000000fb7e 005c00000013 R_390_PC32DBL 0000000000000000 gettimeofday + 2 > 92: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > gettimeofday@GLIBC_2.2 (2) > 442: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > gettimeofday@@GLIBC_2.2 > > Verified that programs from other shared libraries are successfully calling > gettimeofday(). Yet, I die horribly: > > #0 0x000003ff800038ac in ?? () > #1 0x000003fffd6e7576 in waitForAccept (ctl=0xbc3b9300) at lineUtil.c:248 > #2 0x00000000800067a6 in lineTaskV4 (arg=0xbc3b9300) at lineTaskV4.c:230 > #3 0x0000004b5fa292c0 in start_thread () from /lib64/libpthread.so.0 > #4 0x0000004b5f9730b2 in thread_start () from /lib64/libc.so.6 > > According to the process map the address it’s branching to is not in the map. > > All I can think of is that I created the shared library incorrectly: > > gcc –g –fPIC –o lineUtil.o lineUtil.c > : > gcc –shared –o libxxx.so lineUtil.o ... > > Anyone spot my stupidity (restrict your answers to the case in hand). > > Neale > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
