Re: [parisc-linux] Re: gcj can't make shared libs on hppa
John David Anglin writes: please see http://bugs.debian.org/353346 Should be fixed. See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html with this change (and the typo fix), gcj-dbtool segfaults: (gdb) run -n classmap.db Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 6962)] [New Thread 32769 (LWP 6965)] [New Thread 16386 (LWP 6966)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 6962)] linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:776 776 unwind-dw2-fde.c: No such file or directory. in unwind-dw2-fde.c I just remembered, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334112 Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
John David Anglin writes: please see http://bugs.debian.org/353346 Should be fixed. See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html with this change (and the typo fix), gcj-dbtool segfaults: (gdb) run -n classmap.db Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 6962)] [New Thread 32769 (LWP 6965)] [New Thread 16386 (LWP 6966)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 6962)] linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:776 776 unwind-dw2-fde.c: No such file or directory. in unwind-dw2-fde.c (gdb) bt #0 linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:776 #1 0x400af174 in linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3) at unwind-dw2-fde.c:794 Previous frame identical to this frame (corrupt stack?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
John David Anglin writes: please see http://bugs.debian.org/353346 Should be fixed. See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html with this change (and the typo fix), gcj-dbtool segfaults: (gdb) run -n classmap.db Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 6962)] [New Thread 32769 (LWP 6965)] [New Thread 16386 (LWP 6966)] Program received signal SIGSEGV, Segmentation fault. It's not doing this is my GCC builds. Could this be a path problem? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
please see http://bugs.debian.org/353346 Should be fixed. See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
The reason for the segmentation fault is the R_PARISC_IPLT isn't being handled correctly and the indirect call to the constructor for the library branches to the wrong location. here's what i see __do_global_ctors_aux is trying to load a value from the GOT (__CTORS_LIST i think). I'm seeing that it loads some garbage value (0x4fd23f01 in my case), and then it tries to do a $dyncall on that. __do_global_ctors_aux does something like: addil 0(%r19),%r1 ldw 28(%r1),%ret0 ldw -4(%ret0),%r3 ... copy %r3,%r22 b,l $$dyncall, %r31 $r19+0x28 is 0x41896830; points inside the .plt. seems reasonable but *(%ret0-4) points inside the text section, so r22 eventually gets loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18) dunno if this helps with anything... have to think about it somemore to see what's happening... randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
but *(%ret0-4) points inside the text section, so r22 eventually gets loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18) r22 should be pointing to a function descriptor and have the plabel bit set. It's a relative rare situation when an indirect call can be made directly (no shared libraries). Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: gcj can't make shared libs on hppa
Right, it's a linker bug. The following plabel is dropped from the shared library. 000c R_PARISC_PLABEL32 .L_ZN2A1C1Ev0 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: 00010f34 R_PARISC_PLABEL32 *ABS*+0x00010f46 00010f44 R_PARISC_IPLT *ABS*+0x09a8 The reason for the segmentation fault is the R_PARISC_IPLT isn't being handled correctly and the indirect call to the constructor for the library branches to the wrong location. 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 Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
