public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* porting libgcj to PalmOS
@ 1999-12-29  5:13 Peter Mortier
  1999-12-29  8:29 ` Alexandre Petit-Bianco
  1999-12-29 11:06 ` Tom Tromey
  0 siblings, 2 replies; 9+ messages in thread
From: Peter Mortier @ 1999-12-29  5:13 UTC (permalink / raw)
  To: java-discuss

Hello list,

I'm very interested in getting libgcj ported to the PalmOS. Has anybody
tried this yet?
I have already built a gcc cross-compiler and necessary tools for the PalmOS
target on my Linux machine. Basically, I don't care about porting threads,
no threads will do just fine for starters. Nor am I interested in porting
the file system, nor AWT, I'll use CNI instead to write-to/read-from Palm
databases and paint to the Screen. Real support for AWT and file system
could be added later on.

Could anybody give me some pointers on how to get started with adding a new
target? Does the boehm-gc have to be ported? What other issues could be of
importance? Any feedback will be greatly appreciated!

Thanks,

Peter Mortier

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: porting libgcj to PalmOS
  1999-12-29  5:13 porting libgcj to PalmOS Peter Mortier
@ 1999-12-29  8:29 ` Alexandre Petit-Bianco
  1999-12-29  9:50   ` Peter Mortier
  1999-12-29 11:06 ` Tom Tromey
  1 sibling, 1 reply; 9+ messages in thread
From: Alexandre Petit-Bianco @ 1999-12-29  8:29 UTC (permalink / raw)
  To: java-discuss

Peter Mortier writes:

> I have already built a gcc cross-compiler and necessary tools for the PalmOS
> target on my Linux machine.

Is it prc-0.5.0 or the egcs based toolchain? The set of patches for
latter would be necessary in order to get gcj (the egcs patches are
based on 2.95.2) and some of the fixes absolutely necessary to have
libgcj running (like an improved C++ runtime support.)

> Does the boehm-gc have to be ported?

You can configure libgcj not to use a garbage collector. In the
future, it would probably easier to use the memory management API
defined by libcj to craft a GC using the specificities of the PalmOS
memory management (handles, etc...)

./A

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: porting libgcj to PalmOS
  1999-12-29  8:29 ` Alexandre Petit-Bianco
@ 1999-12-29  9:50   ` Peter Mortier
  1999-12-29 10:05     ` Alexandre Petit-Bianco
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Mortier @ 1999-12-29  9:50 UTC (permalink / raw)
  To: Alexandre Petit-Bianco, java-discuss

Alexandre Petit-Bianco wrote:
>
> > I have already built a gcc cross-compiler and necessary tools
> for the PalmOS
> > target on my Linux machine.
>
> Is it prc-0.5.0 or the egcs based toolchain? The set of patches for
> latter would be necessary in order to get gcj (the egcs patches are
> based on 2.95.2) and some of the fixes absolutely necessary to have
> libgcj running (like an improved C++ runtime support.)
>
I've actually experimented quite a bit, this is what I got on my system
Linux x86 Redhat 6.2:
1) prc-0.5.0 tools, cross-compiles fine Palm applications written in C++, no
gcj
2) EGCS based toolchain, with binutils binutils 2.9.1, gdb4.18, gcc2.95.2
and the latest patches from John Marshall, to build a cross-compiler for
PalmOS. Patches and builds fine, except for java support, build chokes,
again no gcj :(
3) 21/12/99 snapshot of EGCS, native compiler. with gcj support and 21/12/99
snapshot of libgcj compiled. Compiled and ran some basic Java applications,
and even tried some CNI, works like a charm.

So currently, I've basically got the following problems:
1) getting gcj to work as a front-end for my gcc-Palm-cross-compiler.
2) building a suitable libgcj for the PalmOS: I've already started modifying
some of the config files of the libgcj, trying to figure out how libgcj
works and builds (there is not a lot documentation, you know)

I'll wory about the gc in a later stage.

Thanks,

Peter Mortier

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: porting libgcj to PalmOS
  1999-12-29  9:50   ` Peter Mortier
@ 1999-12-29 10:05     ` Alexandre Petit-Bianco
  1999-12-29 10:41       ` Peter Mortier
  1999-12-29 11:10       ` Tom Tromey
  0 siblings, 2 replies; 9+ messages in thread
From: Alexandre Petit-Bianco @ 1999-12-29 10:05 UTC (permalink / raw)
  To: java-discuss

Peter Mortier writes:

> 2) EGCS based toolchain, with binutils binutils 2.9.1, gdb4.18,
> gcc2.95.2 and the latest patches from John Marshall, to build a
> cross-compiler for PalmOS. Patches and builds fine, except for java
> support, build chokes, again no gcj :(

I guess I'll have to give it a try (I never tried the egcs patches,
since they weren't stable at the time I was looking for a PlamOS
toolchain. I'm still using prc 0.5.0) How does the build choke? I'm
guessing that by `no gcj' you mean the gcj build failed...

> 1) getting gcj to work as a front-end for my gcc-Palm-cross-compiler.

Unless gcj crashes compiling Java sources... Let us know.

> 2) building a suitable libgcj for the PalmOS: I've already started
> modifying some of the config files of the libgcj, trying to figure
> out how libgcj works and builds (there is not a lot documentation,
> you know)

You'll have to ask details to the libgcj maintainers on how libgcj
relies on C++ global ctor/dtor. I know there was problems with the C++
front-end in the past. They should be taken care of with egcs patches,
I think.

As far as porting libgcj to PalmOS, I'm just worried about the
footprint of the resulting library (or libraries, since each library
has a 32K limit.)

Otherwise, other questions (after having read
http://www.io.com/~jsproat/geocities.old/GNU_Pilot_SDK.txt ) for the
libgcj hackers are:

  - Does libgcj allocate more than 32K at a time?
  - Does libgcj deliberately uses stack frames bigger than 5K?

./A

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: porting libgcj to PalmOS
  1999-12-29 10:05     ` Alexandre Petit-Bianco
@ 1999-12-29 10:41       ` Peter Mortier
  1999-12-29 11:10       ` Tom Tromey
  1 sibling, 0 replies; 9+ messages in thread
From: Peter Mortier @ 1999-12-29 10:41 UTC (permalink / raw)
  To: java-discuss

> Alexandre Petit-Bianco wrote on: Wednesday, December 29, 1999 7:06 PM
>
> I guess I'll have to give it a try (I never tried the egcs patches,
> since they weren't stable at the time I was looking for a PlamOS
> toolchain. I'm still using prc 0.5.0) How does the build choke? I'm
> guessing that by `no gcj' you mean the gcj build failed...
>

Build of GCC-2.95.2 with prc-0.6.0 alpha patches fails when specifying
"--enable-languages=c,c++,java" as flag. The build fails when building the
java (gcj) support:

cd java; make "AR_FLAGS_FOR_TARGET=rc" "AR_FOR_TARGET=m68k-palmos-ar"
"BISON=bison" "BISONFLAGS=" "CFLAGS=-g -O2" "CLIB="
"GCC_FOR_TARGET=/home/peter/gnusrc/build-gcc/gcc/xgcc -B/home/peter/gnusrc/b
uild-gcc/gcc/ -B/usr/local/m68k-palmos/bin/ -I/usr/local/m68k-palmos/include
" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln" "LN_S=ln -s"
"MAKEINFO=/home/peter/gnusrc/build-gcc/texinfo/makeinfo/makeinfo "
"MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=m68k-palmos-ranlib"
"RANLIB_TEST_FOR_TARGET=[ -f m68k-palmos-ranlib ] || ( [ "i586-pc-linux-gnu"
= "m68k-palmos-coff" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )"
"SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "build_exeext=" "objext=.o"
"exec_prefix=/usr/local" "prefix=/usr/local" "local_prefix=/usr/local"
"gxx_include_dir=/usr/local/lib/gcc-lib/m68k-palmos/2.95.2-kgpd/../../../..`
echo /usr/local | sed -e 's|^/usr/local||' -e
's|/[^/]*|/..|g'`/include/g++-3" "tooldir=/usr/local/m68k-palmos"
"gcc_tooldir=/usr/local/lib/gcc-lib/m68k-palmos/2.95.2-kgpd/../../../../m68k
-palmos" "bindir=/usr/local/bin"
"libsubdir=/usr/local/lib/gcc-lib/m68k-palmos/2.95.2-kgpd"
"datadir=/usr/local/share" "distdir=../tmp/\$(subdir)"
"localedir=/usr/local/share/locale" "CC=gcc" "JAVA_FOR_BUILD=" "JAVAFLAGS="
"JAVA_FOR_TARGET=" ../jc1
make[2]: Entering directory `/home/peter/gnusrc/build-gcc/gcc/java'
rm -f ../jc1
gcc  -DIN_GCC    -g -O2   -o ../jc1 \
      parse.o class.o decl.o expr.o constants.o lang.o typeck.o except.o
verify.o zextract.o jcf-io.o jcf-parse.o mangle.o jcf-write.o buffer.o
check-init.o jcf-depend.o jcf-path.o xref.o `cat ../stamp-objlist` `if
 xobstack.o != x ]; then echo ../obstack.o; else true; fi`
../../libiberty/libiberty.a
../m68k.o: In function `palmos_valid_machine_decl_attribute':
/home/peter/gnusrc/build-gcc/gcc/../../gcc-2.95.2/gcc/config/m68k/m68k.c:190
: undefined reference to `lang_identifier_value'
collect2: ld returned 1 exit status
make[2]: *** [../jc1] Error 1
make[1]: *** [jc1] Error 2
make: *** [all-gcc] Error 2make[2]: Leaving directory
`/home/peter/gnusrc/build-gcc/gcc/java'
make[1]: Leaving directory `/home/peter/gnusrc/build-gcc/gcc'

>
> As far as porting libgcj to PalmOS, I'm just worried about the
> footprint of the resulting library (or libraries, since each library
> has a 32K limit.)
>

If you take a look at http://homepages.enterprise.net/jmarshall/palmos/ .
John mentions that one of the new features is:
"Almost transparent support for multiple code resources. (Finally: the 32K
code size barrier truly broken!) ".
My estimations for a limited class library are about 50k (in class files),
so probably somewhat larger in m68k instructions. So this would appear to be
workable, right?

Thanks,

Peter Mortier

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: porting libgcj to PalmOS
  1999-12-29  5:13 porting libgcj to PalmOS Peter Mortier
  1999-12-29  8:29 ` Alexandre Petit-Bianco
@ 1999-12-29 11:06 ` Tom Tromey
  2000-04-01  0:00   ` Kresten Krab Thorup
  1 sibling, 1 reply; 9+ messages in thread
From: Tom Tromey @ 1999-12-29 11:06 UTC (permalink / raw)
  To: Peter Mortier; +Cc: java-discuss

>>>>> "Peter" == Peter Mortier <pmlist@BIGFOOT.COM> writes:

Peter> I'm very interested in getting libgcj ported to the PalmOS. Has
Peter> anybody tried this yet?

I haven't heard of anybody doing it.  It sounds like a great idea!

Peter> I have already built a gcc cross-compiler and necessary tools
Peter> for the PalmOS target on my Linux machine. Basically, I don't
Peter> care about porting threads, no threads will do just fine for
Peter> starters.

Ok, that makes things a bit easier.

Peter> Nor am I interested in porting the file system, nor AWT, I'll
Peter> use CNI instead to write-to/read-from Palm databases and paint
Peter> to the Screen. Real support for AWT and file system could be
Peter> added later on.

Ok, you'll want the ecos file system code then -- it just stubs
everything out.  This hasn't been tried in a while, so it is possible
that it won't fully work.

Peter> Could anybody give me some pointers on how to get started with
Peter> adding a new target? Does the boehm-gc have to be ported? What
Peter> other issues could be of importance? Any feedback will be
Peter> greatly appreciated!

As Alex points out, porting the GC isn't necessary at first, but at
some point you will want to do it (unless you plan to write all of
your code in a strange style).

There are also miscellaneous bits of code that need some function or
another frmo the C library.  These aren't very well organized.
Basically I think you will have to change configure to know about the
Palm target.  You will need to add code so that configuring for the
Palm uses the ecos filesystem code, no-gc by default, etc.  You may
also want to modify the code that does function checks for embedded
builds not to assume newlib, but instead add a new case for the Palm.
I'm afraid this area is a bit ugly still.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: porting libgcj to PalmOS
  1999-12-29 10:05     ` Alexandre Petit-Bianco
  1999-12-29 10:41       ` Peter Mortier
@ 1999-12-29 11:10       ` Tom Tromey
  1 sibling, 0 replies; 9+ messages in thread
From: Tom Tromey @ 1999-12-29 11:10 UTC (permalink / raw)
  To: Alexandre Petit-Bianco; +Cc: java-discuss

>>>>> "Alex" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

>> 2) building a suitable libgcj for the PalmOS: I've already started
>> modifying some of the config files of the libgcj, trying to figure
>> out how libgcj works and builds (there is not a lot documentation,
>> you know)

There is some documentation on porting libgcj, but it is mostly
concerned with the parts you say you don't want to port :-(.
Unfortunately porters are assumed to be autoconf experts as well.  The
good news is that we're happy to provide advice.

Alex> You'll have to ask details to the libgcj maintainers on how
Alex> libgcj relies on C++ global ctor/dtor.

There are a few variables in libgcj that rely on global constructors.
These must be run before main().  I thought gcj generated some code
like this, too, in some situations?

Alex>   - Does libgcj allocate more than 32K at a time?

Probably not, but I'm not 100% sure.

Alex>   - Does libgcj deliberately uses stack frames bigger than 5K?

Again, probably not, but of course user code can do basically
anything.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: porting libgcj to PalmOS
  1999-12-29 11:06 ` Tom Tromey
@ 2000-04-01  0:00   ` Kresten Krab Thorup
  2000-04-01  0:00     ` Tom Tromey
  0 siblings, 1 reply; 9+ messages in thread
From: Kresten Krab Thorup @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Peter Mortier, java-discuss

As far as I can see, there are quite alot of problems to overcome to
make gcj work on the pilot.  (I did the original port which is
currently just a patch floating around along with prc-tools).

1) Constructors/destructors doesn't work on the palm platform as far
   as I know.  This might not be too hard to fix, though.

2) The resulting libgcj library is likely to be quite large,

3) All the basic java libraries (java.*) are quite intertwined, and
   require alot of basic libc stuff; which is not available on PalmOS.
   Thus, it would be a lot of work to create a "trimmed down" version.

4) Finally, it is unreasonable to write meaningful java programs
   without a garbage collector.

If someone starts working seriously on it, I might able to be of some
help with bullet (1) above.

-- Kresten

 Kresten Krab Thorup           "I like my eggs ploded"
 Department of Computer Science, University of Aarhus
 Aabogade 34, DK-8200 Aarhus N, Denmark
 +45 8942 5665 (office), +45 2343 4626 (mobile)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: porting libgcj to PalmOS
  2000-04-01  0:00   ` Kresten Krab Thorup
@ 2000-04-01  0:00     ` Tom Tromey
  0 siblings, 0 replies; 9+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Kresten Krab Thorup; +Cc: Tom Tromey, Peter Mortier, java-discuss

>>>>> "Kresten" == Kresten Krab Thorup <krab@daimi.au.dk> writes:

Kresten> As far as I can see, there are quite alot of problems to
Kresten> overcome to make gcj work on the pilot.

Kresten> 3) All the basic java libraries (java.*) are quite
Kresten>    intertwined, and require alot of basic libc stuff; which
Kresten>    is not available on PalmOS.  Thus, it would be a lot of
Kresten>    work to create a "trimmed down" version.

This is something we've wanted to be able to do: configure libjava in
various configurations to omit pieces of code that are not wanted for
a particular build.  We don't have a real design here; currently we
can omit java.net in a rather hacky way, but I don't think we want to
go much further down that path.  One idea we've had is to use "section
GC" in the linker to omit code at link time; in some situations that
will probably be good enough.

Tom

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-29  5:13 porting libgcj to PalmOS Peter Mortier
1999-12-29  8:29 ` Alexandre Petit-Bianco
1999-12-29  9:50   ` Peter Mortier
1999-12-29 10:05     ` Alexandre Petit-Bianco
1999-12-29 10:41       ` Peter Mortier
1999-12-29 11:10       ` Tom Tromey
1999-12-29 11:06 ` Tom Tromey
2000-04-01  0:00   ` Kresten Krab Thorup
2000-04-01  0:00     ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).