Re: GCJ on mipsel-unknown-linux-gnu

[David Daney <ddaney at avtrex dot com>]

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.

Attachment: gcc332.diff.gz
Description: GNU Zip compressed data