RFR: 8370314: Update signals_posix with new Linux signal codes [v2]

[Thomas Stuefe]

On Thu, 8 Jan 2026 19:45:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > > > FWIW, @tstuefe added checks like this (minus the proposed macro) when introducing the `MAP_FIXED_NOREPLACE` define in os_linux.cpp: [3699666](https://github.com/openjdk/jdk/commit/3699666c9325b38d287e1d4d2576f8e3a662ae81)
> > > 
> > > 
> > > Yes but in that case we knew the problem was that it did in fact have different values.
> > 
> > 
> > I don't see anything in the PR or JBS that supports this statement.
> 
> ```
> // Note that the value for MAP_FIXED_NOREPLACE differs between architectures, but all architectures
> // supported by OpenJDK share the same flag value.
> ```
> 
> But I see we also did this for SEGV_BNDERR so I will use the same pattern.

The MAP_FIXED_NOREPLACE thing was caused by Oracle kernel devs having integrated an Oracle-only patch that later broke binary compatibility if the user program was not compiled on an Oracle machine. It was a security issue. I reported it to Oracle, and they have fixed it by now.

> Though I still think this overly cautious approach is protecting against the "impossible". If the value were ever changed then no binaries compiled on a previous version would work - that is simply not a change that is going to happen.

You'd think that. I thought this also for MAP_ ... constants. But downstream vendors do make errors, as we saw.

But I guess these constants are probably harmless, even if they are wrong. So I am fine with omitting the check here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29105#issuecomment-3737961309