JDK 9 fails to build on MIPS

James Cowgill jcowgill at debian.org
Thu Dec 1 12:03:22 UTC 2016


Thanks for looking at my patch!

On 30/11/16 19:33, Thomas Stüfe wrote:
> In general I like your patch - we used sigset_t in the AIX port instead
> of masks and this would be a good cleanup for the other platforms too. 
> But in this case, is the problem not that the mips signal.h headers
> fails to define NSIG?
> We have NSIG and _NSIG. _NSIG seems to be the platform dependent max
> including real time signals. NSIG excludes real time signals, and seems
> to be 32 (SIGRTMIN) on all Linux platforms I checked. 

I'm running Ubuntu 16.04 (amd64) and both NSIG and _NSIG are 65 here.

> I may have looked wrong (I searched
> http://lxr.free-electrons.com/ident?v=3.2&i=NSIG), but I found that NSIG
> was missing from signal.h on some architectures, mips being among them.
> I do not know why, but would like to understand the reason. Do you
> define NSIG to be _NSIG?

My reading of glibc's signal.h seems to indicate that all architectures
which use glibc define NSIG = _NSIG. The kernel and glibc headers quite
often disagree (struct stat springs to mind).

The glibc documentation on this also doesn't mention real time signals:

Macro: int NSIG
The value of this symbolic constant is the total number of signals
defined. Since the signal numbers are allocated consecutively, NSIG is
also one greater than the largest defined signal number.

> The VM currently does not use real time signals, so NSIG should be
> sufficient. If NSIG is really missing on mips, then maybe defining it
> locally as SIGRTMIN would be a less invasive change. 

Maybe we could use something other than NSIG as the maximum signal
(although I'm not sure I like it that much)? SIGRTMIN is not a constant
on glibc systems so redefining NSIG isn't going to work as a quick fix.

> If we were to change the hand-written bitmask to sigset_t, we probably
> should also take a look at the arrays of length NSIG (sigact, sigflags,
> pending_signals) and the associated checks. This would be a bigger cleanup.

I think that's a separate bug though. The bug here is that we're _not_
using an array - we're using a fixed sized integer instead.

> ---
> Apart from all that, I'd suggest moving the sigset initialization in
> os_linux.cpp from the "__attribute__((constructor))" function to
> os::signal_init_pd(). I'd suggest a similar move for jsig.c, but do not
> see a suitable initialization function there. Maybe someone else has an
> idea?

Ok I'll do that when I do another patch.


> On Wed, Nov 30, 2016 at 6:50 PM, James Cowgill <jcowgill at debian.org
> <mailto:jcowgill at debian.org>> wrote:
>     Hi,
>     Firstly I have never submitted anything to OpenJDK before so apologies
>     if I haven't done things the right way. I also have no bug number
>     for this.
>     OpenJDK 9 does not build on MIPS machines and hasn't for some time. This
>     is due to code in hotspot which assumes NSIG <= 65 which is not the case
>     on MIPS since MIPS has 127 signal numbers.
>     I've attached an initial patch which converts the offending code in
>     hotspot/src/os/linux/vm/jsig.c to use sigset_t instead of an array to
>     store the used signals. I notice the AIX implementation of jsig.c
>     already does this.
>     Originally from: https://bugs.debian.org/841173
>     Thanks,
>     James

More information about the hotspot-dev mailing list