--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
14:41 ---
I think this is a libffi problem in that it creates a closure but does not make
it exutable.
--
What|Removed |Added
-
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-08 19:25
---
I don't think this is a libffi problem. gcj allocates trampolines on the heap,
not the stack.
I think this is a multilib problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
--- Additional Comments From mckinlay at redhat dot com 2005-02-09 04:11
---
Note that TestProxy is failing too, which does seem to indicate a problem with
ffi closures.
boehm-gc does have code to call mprotect() on its heap (see PROTECT/UNPROTECT in
os_dep.c), but it isn't used because
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-09 05:38
---
I believe that the GC alters permissions on the heap only if either
- It is running in incremental mode, or
- It is built with USE_MMAP, and thus uses mmap to allocate the heap.
I think we talked about always
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-09 10:47
---
I changed the gc settings to enable USE_MMAP on Linux.
I had to do this because at least one Linux kernel didn't give exec permission
on the heap. That change did work at the time.
2004-01-20 Andrew Haley <[
--
What|Removed |Added
CC||aj at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-09 18:27
---
I looked at my build dir (4.0 CVS) and everything looks ok. I guess
I should run some strace - could somebody tell me how to invoke gij
from the commandline in a simple case so that I can check this?
--
h
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-09
20:09 ---
I'm not so sure that the patch to always define USE_MMAP really
has that effect. By my reading this patch is revision 1.36, but
if you diff against 1.35 and then go look at include/private/gcconfig.h,
it loo
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-10 00:33
---
I agree with Tom's interpretation. The define for USE_MMAP only affects
M68K/LINUX. Confirmed with strace on IA/64.
I'd prefer to see the USE_MMAP definition in a gcj-specific configuration
file. I'd lik
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-10 06:11
---
I agree, the USE_MMAP is not global. I'm trying now the following patch to see
whether we're really on the right track:
Index: boehm-gc/include/pri
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-10 09:22
---
With my patch, the results look good again (this is on x86-64 with multilibs):
=== libjava Summary for unix ===
# of expected passes3726
# of expected failures 14
# o
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-10 10:58
---
It looks like the patch was applied to the wrong place in the file: it certainly
was my intention to apply it to all Linux. And indeed, my testing was not on
m68k, but on x86-64.
The obvious question is whethe
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-14 14:56
---
We need to make this change soon. I'd like to do something that Hans would
approve of, but I don't know exactly what that might be.
Andreas Jaeger says his patch works. Unless someone comes up with something
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-14 15:07
---
Is it desirable to have all memory allocated by the GC executable though?
I think libgcj always knows in advance what memory will it need executable,
so wouldn't it be better to provide separate allocation ent
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-14 15:18
---
This seems to me like creeping featurism.
We need to distinguish between fixing this bug in a simple way and adding "nice"
new properties that would require a change to the garbage collector's API. At
this sta
--- Additional Comments From Hans dot Boehm at hp dot com 2005-02-14 19:38
---
I'd like to see USE_MMAP set in boehm-gc/configure.ac instead of gcconfig.h.
There's already a comment there that we're not setting NO_EXECUTE_PERMISSION
for this reason, where the upstream version does set
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-16
04:10 ---
Subject: Bug 19823
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-16 04:10:42
Modified files:
boehm-gc : ChangeLog configure.ac configure.host
--- Additional Comments From mckinlay at redhat dot com 2005-02-16 04:22
---
Michael (or someone else who has seen this bug),
Could you confirm that this patch fixes it?
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
19:01 ---
Subject: Bug 19823
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-22 19:00:40
Modified files:
boehm-gc : Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
19:02 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|NEW |RESOL
20 matches
Mail list logo
