gcj can't make shared libs on hppa]
Dave,
Sorry, it appears I've been dropped from various lists when my mail servers went down due to university problems.
Quoted 9 lines
Quoted 4 lines
Right, it's a linker bug. The following plabel is dropped from the shared library.
0000000cR_PARISC_PLABEL32.L_ZN2A1C1Ev0I was too hasty in calling this a linker bug. We end up with the following relocations in the shared library as a result of the above relocation in the object file:
Quoted 6 lines
00010f34R_PARISC_PLABEL32*ABS*+0x00010f4600010f44R_PARISC_IPLT*ABS*+0x000009a8The reason for the segmentation fault is the
R_PARISC_IPLTisn't being handled correctly and the indirect call to the constructor for the library branches to the wrong location.
Can you explain what is broken?
Where does it branch to?
Quoted 6 lines
Carlos, do you have an opinion on how plabels that reference local symbols in shared libraries should be handled? This is what we have in the A1.s file for .L_ZN2A1C1Ev0:
.word P%.L_ZN2A1C1Ev0 .set .L_ZN2A1C1Ev0,_ZN2A1C1Ev
*ABS* IPLT relocations might be mildly broken in hppa actually.
*ABS* PLABEL's point to the PLT at runtime, this might be a reason for the breakage. We point them at the PLT because they are local and thus the PLT is a unique OPD.
It might be possible the IP is correctly set, but the GP is incorrect. If you could verify this it would be great?
This breakage would have occured around the time that fixup was changed to incorporate ia64 changes.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 4 lines
Quoted 4 lines
I was too hasty in calling this a linker bug. We end up with the following relocations in the shared library as a result of the above relocation in the object file:
Quoted 8 lines
Quoted 6 lines
00010f34R_PARISC_PLABEL32*ABS*+0x00010f4600010f44R_PARISC_IPLT*ABS*+0x000009a8The reason for the segmentation fault is the
R_PARISC_IPLTisn't being handled correctly and the indirect call to the constructor for the library branches to the wrong location.Can you explain what is broken?
If I knew that, I probably would have fixed the problem ;(
Quoted 1 line
Where does it branch to?
(gdb) stepi0x400abb94 in __do_global_ctors_aux () from ./liba1.so.0 (gdb)0x400ab9c4 in $$dyncall () from ./liba1.so.0 (gdb)0x400ab9c4 in $$dyncall () from ./liba1.so.0 (gdb)0x400ab9d4 in $$dyncall () from ./liba1.so.0 (gdb)0x400ab9d8 in $$dyncall () from ./liba1.so.0 (gdb)0x08000240 in ?? ()
(gdb) stepi
Program received signal SIGSEGV, Segmentation fault. 0x08000240 in ?? ()
Starting program: /home/dave/gcc_test/main
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 29346)]
[Switching to Thread 16384 (LWP 29346)]
Breakpoint 3, 0x400abb90 in __do_global_ctors_aux () from ./liba1.so.0 (gdb) p/x $r22
$3 = 0x8000240
This is just before the call to $$dyncall. As can be seen, $r22 doesn't point to a function descriptor. There doesn't seem to be a function at 0x8000240.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux