GCJ on mipsel-unknown-linux-gnu

David Daney ddaney@avtrex.com
Thu Apr 15 18:17:00 GMT 2004


Casey Marshall wrote:

>Hi. I'm currently trying to get gcj 3.3.3 up and working on
>mipsel-linux, and have gotten pretty far by patching the 3.3.3 release
>with the diffs listed here:
><http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00902.html>
>
>But I've caught a few snags. My first question is whether or not there
>are any other patches that I should try incorporating besides those in
>the above URL.
>

Try the attached patch instead.  It is against 3.3.2, but the changes 
for 3.3.3 should be very similar.  They only work against glibc, I have 
not yet been successful in getting it to work with uClibc.

Also this version of the patch strips out many classes from libgcj that 
I don't need.  If you need those classes, you will have to modify the 
Makefile.am part of the patch.

This version of the patch is essentially a back port of what is 
currently in 3.4.

>
>The first obvious problem I have is that stack traces aren't pretty;
>they are composed of just addresses and "Unknown Source". I understand
>that libgcj will try to use dladdr to resolve the function names, but
>that dladdr doesn't work on mips (and indeed, if I remove the
>`disable_dladdr' line in configure.host, dladdr (or something called
>by it) hits a SEGV). The `c++filt'/`addr2line' hack doesn't work,
>because addr2line 2.14 can't seem to resolve function names in shared
>libraries (I am pretty much forced to use dynamic linking right now,
>since just about everything I am trying to run needs to load classes
>dynamically).
>  
>

I have stacktraces printing out filenames and line numbers also.   I 
think I just have a recent version of addr2name, and have removed 
addr2name.awk.  The addresses in libgcj and libc don't decode,but those 
in the main executable do, and that can be helpful.

>GNU Awk 3.1.3 seems to really dislike `addr2name.awk'. It fails with
>this:
>
>   sh: -c: line 1: syntax error near unexpected token `|'
>   sh: -c: line 1: ` | sort'
>
>which looks like a newline is being inserted at the end of ARGV[1]:
>
>   object = ARGV[1];
>   ...
>   while ("nm " object "| sort" | getline) {
>
>I also see that --enable-interpreter doesn't work. Is this an issue
>with libffi? That's what it looks like from the compilation errors.
>  
>
libffi has some problems for this port, it is also missing closure 
support which is required by the interpreter.  It is on my list of 
things to fix.  Unfortunatly I have many non-gcc related things on the 
list before fixing libffi.

David Daney.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc332.diff.gz
Type: application/x-gzip
Size: 46737 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040415/12125483/attachment.bin>


More information about the Java mailing list