From: Jack Howarth <howarth@bromo.med.uc.edu>
To: Andrew Haley <aph@redhat.com>
Cc: "Boehm, Hans" <hans.boehm@hp.com>, borlum <thomas@borlum.dk>,
"java@gcc.gnu.org" <java@gcc.gnu.org>
Subject: Re: [patch] Fix oddity in personality routine
Date: Fri, 04 Dec 2009 03:01:00 -0000 [thread overview]
Message-ID: <20091204025943.GA16677@bromo.med.uc.edu> (raw)
In-Reply-To: <4B182CB7.9050605@redhat.com>
On Thu, Dec 03, 2009 at 09:25:11PM +0000, Andrew Haley wrote:
> Boehm, Hans wrote:
> >> From: Jack Howarth
> >> Do you think that -Wl,-allow_stack_execute needs to be
> >> passed even more widely than on just ecjx_LDFLAGS? Any
> >> suggestions as to where I should be passing it? Perhaps on
> >> something like LIBJAVA_LDFLAGS_NOUNDEF at the toplevel of
> >> libjava? Or should we even be building libffi and boehm-gc
> >> with that as well?
> >>
> > I haven't been following this completely, but:
> >
> > The GC also has a compile-time flag NO_EXECUTE_PERMISSION, which affects heap executability.
>
> I think that's probably not the cause, since libffi allocates memory itself.
>
> Andrew.
Andrew,
On reflection, shouldn't something like...
Index: libjava/Makefile.in
===================================================================
--- libjava/Makefile.in (revision 154965)
+++ libjava/Makefile.in (working copy)
@@ -8500,8 +8500,7 @@
$(am__append_28)
gij_SOURCES =
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
gij_LDADD = -L$(here)/.libs libgij.la
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am (revision 154965)
+++ libjava/Makefile.am (working copy)
@@ -294,7 +294,7 @@
LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
GCJLINK = $(LIBTOOL) --tag=GCJ $(LIBTOOLFLAGS) --mode=link $(GCJ) -L$(here) \
- $(JC1FLAGS) $(LTLDFLAGS) -o $@
+ $(extra_gij_ldflags) $(JC1FLAGS) $(LTLDFLAGS) -o $@
GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
LIBLINK = $(LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link $(CXX) -L$(here) \
@@ -1065,8 +1065,7 @@
## need this because we are explicitly using libtool to link using the
## `.la' file.
gij_LDFLAGS = -rpath $(dbexecdir) -rpath $(toolexeclibdir) \
- -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags) \
- $(extra_gij_ldflags)
+ -shared-libgcc $(THREADLDFLAGS) $(extra_ldflags)
gij_LINK = $(GCJLINK) $(gij_LDFLAGS)
## See jv_convert_LDADD.
gij_LDADD = -L$(here)/.libs libgij.la
...be appropriate to make sure that all java executables on darwin are linked with
-Wl,-allow_stack_execute? However, this raises the question of why the gcj and ecj1
compilers aren't doing the same? As I understand this, any executables created
with libraries containing code that executes on the stack (like libgcj) needs
to link the binaries with -Wl,-allow_stack_execute. Shouldn't this apply to
gcj and ecj1 as well since they create executables which are linked against
libgcj? Wouldn't we have to do this by adding the missing -allow_stack_execute flag
to libjava/libgcj.spec.in?
Jack
next prev parent reply other threads:[~2009-12-04 3:01 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 17:49 Eric Botcazou
2009-11-13 17:57 ` Andrew Haley
2009-11-13 18:36 ` Jack Howarth
2009-11-13 18:39 ` Andrew Haley
2009-11-13 19:18 ` Jack Howarth
2009-11-15 23:02 ` Bryce McKinlay
2009-11-16 14:22 ` Jack Howarth
2009-11-16 15:12 ` Jack Howarth
2009-11-16 15:17 ` Andrew Haley
2009-11-16 15:34 ` Jack Howarth
2009-11-16 16:59 ` Andrew Haley
2009-11-16 18:07 ` Jack Howarth
2009-11-16 19:10 ` Andrew Haley
2009-11-16 19:48 ` Jack Howarth
2009-11-17 0:48 ` Jack Howarth
2009-11-17 10:59 ` Andrew Haley
2009-11-17 14:05 ` Jack Howarth
2009-11-17 14:56 ` Andrew Haley
2009-11-17 16:18 ` Jack Howarth
2009-11-17 16:22 ` Andrew Haley
2009-11-17 17:07 ` Jack Howarth
2009-11-17 17:14 ` Andrew Haley
2009-11-17 17:38 ` Jack Howarth
2009-11-27 10:37 ` borlum
2009-11-27 10:40 ` Andrew Haley
2009-11-27 10:52 ` borlum
2009-11-27 14:20 ` Bryce McKinlay
2009-11-27 16:29 ` Jack Howarth
2009-11-27 21:51 ` Jack Howarth
2009-11-28 10:43 ` Andrew Haley
2009-11-29 17:48 ` Jack Howarth
2009-11-29 18:01 ` Andrew Haley
2009-11-29 18:48 ` Jack Howarth
2009-11-30 10:09 ` Andrew Haley
2009-11-30 16:01 ` Jack Howarth
2009-11-30 16:07 ` Andrew Haley
2009-12-01 5:02 ` Jack Howarth
2009-12-01 9:30 ` Andrew Haley
2009-12-01 17:04 ` Jack Howarth
2009-12-01 17:24 ` Andrew Haley
2009-12-01 23:29 ` Jack Howarth
2009-12-02 9:34 ` Andrew Haley
2009-12-03 1:08 ` Jack Howarth
2009-12-03 10:26 ` Andrew Haley
2009-12-03 14:03 ` Jack Howarth
2009-12-03 14:10 ` Andrew Haley
2009-12-03 19:18 ` Boehm, Hans
2009-12-03 21:25 ` Andrew Haley
2009-12-04 3:01 ` Jack Howarth [this message]
2009-12-04 9:45 ` Andrew Haley
2009-12-04 4:12 ` Jack Howarth
2009-12-04 9:44 ` Andrew Haley
2009-12-04 14:51 ` Jack Howarth
2009-12-04 14:59 ` Andrew Haley
2009-12-04 15:23 ` Jack Howarth
2009-12-04 15:48 ` Andrew Haley
2009-12-04 15:57 ` Bryce McKinlay
2009-12-05 4:37 ` Jack Howarth
2009-12-05 6:54 ` Jack Howarth
2009-12-04 15:59 ` Jack Howarth
2009-12-04 16:06 ` Andrew Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091204025943.GA16677@bromo.med.uc.edu \
--to=howarth@bromo.med.uc.edu \
--cc=aph@redhat.com \
--cc=hans.boehm@hp.com \
--cc=java@gcc.gnu.org \
--cc=thomas@borlum.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).