Re: gcj cannot find ecj any more, on m68k
On 05/09/2012 07:55 PM, Thorsten Glaser wrote: > Andrew Haley dixit: > >> gcj has an evil bug. Sometimes, when it has an unresolved reference, it >> reports a ClassNotFoundException for the referring class, not the >> referred. So, you now need to > > Oh, ok. > >> jcf-dump -v -classpath /usr/share/java/eclipse-ecj-3.5.1.jar >> org.eclipse.jdt.internal.compiler.Compiler > > Ok, got a lot of output. > >> and have a look at the class references in the constant pool. > > Uh, I’m sorry you lost me there. That is a train station, right? ;-) > I can barely read any Java™ source code, much less know about gcj > internals other than what I’ve seen during porting… Hmm. Well, I think we're very close and it would be a shame to stop now. If you do an "strace -f -etrace=file" you should be able to see what classes it's trying to load at the end, and one of these won't be found, and one of them wil be mentioned in the list of classes in the jcf-dump. Andrew. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fab7028.6040...@redhat.com
Re: gcj cannot find ecj any more, on m68k
Andrew Haley dixit: >Hmm. Well, I think we're very close and it would be a shame to stop Oh, ok. >now. If you do an "strace -f -etrace=file" you should be able to see >what classes it's trying to load at the end, and one of these won't be >found, and one of them wil be mentioned in the list of classes in the >jcf-dump. I did it to the gij command, as you didn’t specify which, but bad luck, all it does is sitting there for a few minutes after spewing out what I attached. I’ve not had too much luck with strace on m68k for anything since the architecture was forced by glibc maintainers to switch to use TLS but didn’t have a register allocated in the psABI for it, and the porters probably didn’t want to change the ABI so they added syscalls, and now about every single function calls syscall #333 to get the TLS base address which slows strace down to hell. The “just sitting there” is idle though. root@aranym:~ # ps ax | fgrep pts/3 17229 pts/3Ss 0:00 -/bin/mksh 17255 pts/3S+ 1:03 strace -f -etrace=file gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 17256 pts/3S+ 0:00 tee st.log 17257 pts/3Sl+0:35 gij-4.6 -verbose:class -classpath /usr/share/java/eclipse-ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 -ftarget=1.5 17569 pts/4R+ 0:00 fgrep pts/3 Do you reckon a LD_PRELOAD open wrapper would help? (Or are we looking at more functions, if so which?) bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr st.log.gz Description: Binary data
Re: gcj cannot find ecj any more, on m68k
On 05/10/2012 06:08 PM, Thorsten Glaser wrote: > Andrew Haley dixit: > >> Hmm. Well, I think we're very close and it would be a shame to stop > > Oh, ok. > >> now. If you do an "strace -f -etrace=file" you should be able to see >> what classes it's trying to load at the end, and one of these won't be >> found, and one of them wil be mentioned in the list of classes in the >> jcf-dump. > > I did it to the gij command, as you didn’t specify which, but bad luck, > all it does is sitting there for a few minutes after spewing out what > I attached. I’ve not had too much luck with strace on m68k for anything > since the architecture was forced by glibc maintainers to switch to use > TLS but didn’t have a register allocated in the psABI for it, and the > porters probably didn’t want to change the ABI so they added syscalls, > and now about every single function calls syscall #333 to get the TLS > base address which slows strace down to hell. > > The “just sitting there” is idle though. > > root@aranym:~ # ps ax | fgrep pts/3 > 17229 pts/3Ss 0:00 -/bin/mksh > 17255 pts/3S+ 1:03 strace -f -etrace=file gij-4.6 -verbose:class > -classpath /usr/share/java/eclipse-ecj.jar > org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 > -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 > -ftarget=1.5 > 17256 pts/3S+ 0:00 tee st.log > 17257 pts/3Sl+0:35 gij-4.6 -verbose:class -classpath > /usr/share/java/eclipse-ecj.jar > org.eclipse.jdt.internal.compiler.batch.GCCMain x.java -g1 > -fbootclasspath=./:/usr/share/java/libgcj-4.6.jar -g1 -fsource=1.5 > -ftarget=1.5 > 17569 pts/4R+ 0:00 fgrep pts/3 > > Do you reckon a LD_PRELOAD open wrapper would help? > (Or are we looking at more functions, if so which?) Oh, gosh. As you say, it looks like strace isn't working. I can't think of any way I'd investigate this other than using gdb to try to find the place where the exception is being thrown. Andrew. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fabf9c1.6010...@redhat.com
