RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms
sgehwolf at redhat.com
Thu Jun 11 08:05:47 UTC 2015
On Thu, 2015-06-11 at 15:45 +1000, David Holmes wrote:
> On 10/06/2015 11:49 PM, Severin Gehwolf wrote:
> > Hi,
> > Could somebody please review this Zero only change? I'd also need a
> > sponsor who can push the change for me once reviewed.
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8087120
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/
> > The issue is that Zero relies on undefined behaviour for getting the
> > current stack pointer by allocating a variable on the stack and
> > returning its address. With GCC 5 returning an address of a local
> > variable will always be 0, thus causing the issue. It worked fine with
> > older GCC versions, because they returned the actual address of the
> > variable.
> > The fix is to use GCC's built-in function "__builtin_frame_address".
> > This also works on GCC 5. It's GCC specific, though. On the other hand,
> > I don't know if anybody builds Zero without GCC. An alternative would be
> > to use alloca, but that has strange semantics if the stack pointer
> > cannot be extended. Thoughts?
> The Zero folk will need to confirm if this gcc dependency is ok or
> whether it requires an ifdef - and they can also push directly to one of
> the hotspot repos.
Speaking as the Zero maintainer, the GCC dependency is OK. I'd rather
avoid the ifdef. Unfortunately, I am not a committer so cannot push it
myself. I can ask Andrew Haley to push the fix for me once you're OK
> Is the built-in available across gcc 4.x releases?
Looking at the oldest GCC manual I've found for the 4.x series it
appears it's available since 4.0.4. A couple of examples:
More information about the hotspot-dev