RISC-V: add native build spec

[janvrany]

This PR adds a RISC-V native build spec in order to (re) enable OMR CI for RISC-V using RISC-V hardware.
For details see #7530.

[AdamBrousseau]

jenkins build riscv

[AdamBrousseau]

Looks like the container is missing git. I commented in the Eclipse issue.

[AdamBrousseau]

jenkins build riscv

[janvrany]

jenkins build riscv

[AdamBrousseau]

@babsingh can you confirm if we need to change the alias code for riscv vs riscv_cross specs? Seems this is related to adding extra build or test options. Do we leave them both as riscv or should the old one be changed to riscv_cross?

[babsingh]

It makes sense to differentiate between the two variants, i.e., include both riscv and riscv_cross. Otherwise, we lose control over distinguishing between the two builds.

[janvrany]

jenkins build riscv

[janvrany]

@babsingh

It makes sense to differentiate between the two variants, i.e., include both riscv and riscv_cross. Otherwise, we lose control over distinguishing between the two builds.

So you suggest to do the following?

omr/buildenv/jenkins/omrbuild.groovy

Lines 163 to 164 in 62d4368

	'linux_riscv64_cross' : [
	'alias': 'riscv_cross',

and

omr/buildenv/jenkins/omrbuild.groovy

Lines 183 to 184 in 62d4368

	'linux_riscv64' : [
	'alias': 'riscv',

[babsingh]

Yes, just the aliases should differ for the two configurations. If you'd like, you can suggest shorter alias names.

[janvrany]

Looking at (failed) run 6 ( https://ci.eclipse.org/omr/job/PullRequest-linux_riscv64/6/console):

• TestJitBuilderAPIGenerator fails because of Rename deprecated Python unittest function assertRegexpMatches #7279, maybe I can come up with different solution (than Rename deprecated Python unittest function assertRegexpMatches #7279) that would work everywhere.
• porttest fails (wild-guessing) because of core file size limits.

I'll have another look next week.

[janvrany]

jenkins build riscv

[janvrany]

jenkins build riscv

[janvrany]

• porttest fails (wild-guessing) because of core file size limits.

I think I was right. The build runs with core dump size hard limit set to 0, see https://ci.eclipse.org/omr/job/PullRequest-linux_riscv64/26/consoleFull (text-search for "ulimit").

I double checked: on my test docker image core dump tests pass if core file limit is at unlimited or 1MB and fail when set to zero.

I think we need to open an issue with Eclipse CI to increase the limit for us. Or else, disable dump tests.

[janvrany]

I think we need to open an issue with Eclipse C

I went ahead: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5370

[janvrany]

jenkins build riscv

[janvrany]

RISC-V build agent was updated and dump tests are now passing. This leaves only jitbuilder tests failing - hopefully #7181 gets fixed soon (via #7576 or otherwise).

[janvrany]

jenkins build riscv

[janvrany]

jenkins build riscv

[AdamBrousseau]

lgtm from build side.

[babsingh]

The PR build failure is unrelated to the changes in this PR. It's a known issue, which is documented in #7181. @AdamBrousseau The riscv machines need a specific Python version, which supports assertRegexpMatches.

[AdamBrousseau]

Ok. In that case can @janvrany ask in the Eclipse Gitlab ticket for the version we need?

[babsingh]

Ok. In that case can @janvrany ask in the Eclipse Gitlab ticket for the version we need?

#7576 tries to address the issue by replacing the usage of assertRegexpMatches with assertRegex, which is supported in newer Python versions. If this PR is accepted, we won't need to manage/update the Python version on the machines.

[janvrany]

Personally, I'd very much prefer to avoid having custom version of Python. It is not readily available as package - not in Ubuntu, nor in Debian - so it would mean compiling our own and install it (maybe alongside packaged Python). Given that we do not manage the build agent image, feels like lot work not only for us, but also for Eclipse CI team.

Let's wait for #7576 review and see.