--- Comment #13 from tromey at gcc dot gnu dot org 2006-02-08 20:10 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #12 from tromey at gcc dot gnu dot org 2006-02-08 20:07 ---
Subject: Bug 26063
Author: tromey
Date: Wed Feb 8 20:07:29 2006
New Revision: 110763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110763
Log:
PR libgcj/26063, PR libgcj/17978, PR libgcj/10598:
--- Comment #11 from tromey at gcc dot gnu dot org 2006-02-04 02:50 ---
The simplest way to solve the memory leak is to make a new structure
which holds all the data, then allocate an instance of this.
This structure can be allocated with _Jv_AllocBytes, I believe, as the
atable ought to
--- Comment #10 from thebohemian at gmx dot net 2006-02-02 19:26 ---
(From update of attachment 10771)
Forget about this patch. it doesnt compile and there is a working one on the
java-patches list.
--
thebohemian at gmx dot net changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-02 12:56 ---
PR 26073 is the PR for ffi usage that breaks ARM.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from thebohemian at gmx dot net 2006-02-02 12:56 ---
Created an attachment (id=10771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10771&action=view)
a preliminary patch (not tested)
Unfortunately I am in a hurry and have to leave soon. If anyone depends on the
ARM
--- Comment #7 from thebohemian at gmx dot net 2006-02-02 12:52 ---
Changed the title and have a preliminary patch.
--
thebohemian at gmx dot net changed:
What|Removed |Added
-
--- Comment #6 from aph at gcc dot gnu dot org 2006-02-02 12:10 ---
See java/lang/reflect/natMethod.cc:
#if USE_LIBFFI
#include
#else
#include
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063
--- Comment #5 from thebohemian at gmx dot net 2006-02-02 12:06 ---
The ffi usage breaks the build on arm :(
Can someone tell me which macro I can use to test ffi availability?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063
--- Comment #4 from tromey at gcc dot gnu dot org 2006-02-01 18:32 ---
FWIW, some embedded users want to be able to remove ffi --
not for its own sake but because they also want to remove
the interpreter, reflection info (see David Daney's recent
proposal). It doesn't seem that hard to
--- Comment #3 from aph at gcc dot gnu dot org 2006-02-01 16:57 ---
Working around the lack of libffi support on ARM is Just Plain Stupid. We
should either fix it or cease to build on ARM. Without libffi libgcj cannot
work in any reasonable way.
The memory leak thing can be fixed by u
--- Comment #2 from thebohemian at gmx dot net 2006-02-01 16:52 ---
Added aph to get some ideas on how to solve this.
Some ideas:
The code that uses the ffi structure is so complicated because it is neccessary
to prepare a call that takes one argument (a class name). I plan to put setup
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-01 14:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
13 matches
Mail list logo
