[SOLVED] monero fails to execute (Illegal instruction)

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

Hi,
I'm having issue with net-p2p/monero. I opened a bug here if you want the long version : https://github.com/gentoo-monero/gentoo-monero/issues/18
Otherwise, tldr :

When I build the package inside a core2 chroot on my amd system, the binary cannot be executed on my core2 laptop (Illegal instruction)
But if I compile directly the package on the core2 laptop, then it works fine.

I suspect that when the package is built inside the chroot, it somehow picks up the AES instruction from my amd cpu, which could explain the illegal instruction I think.

My chrooted core2 install make.conf is :

eccerr0r · Posted: Fri Aug 13, 2021 10:41 pm Post subject:

First off the CPU_FLAGS_X86 if not in ebuild, are usually ignored, but this isn't what you're seeing.

It's quite possible that the build system of the underlying package simply ignores CFLAGs passed to it and makes its own. A copy of the build log, if it doesn't truncate it, would be interesting.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Anon-E-moose · Posted: Fri Aug 13, 2021 10:59 pm Post subject:

I build pkgs for my acer laptop (i3) on my ryzen machine, and use this setting

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

Anon-E-moose · Posted: Fri Aug 13, 2021 11:44 pm Post subject:

By rights, it shouldn't be trying to use the aes instruction when using a particular march= that doesn't have it native, but I've seen funny behavior when I don't explicitly turn off flag(s).

Edit to add:
You could run this to see what the differences are

diff -U0 <(LANG=C gcc -Q -O2 -march=skylake --help=target) <(LANG=C gcc -Q -O2 -march=znver2 --help=target)

change skylake and znver2 as appropriate.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

eccerr0r · Posted: Fri Aug 13, 2021 11:46 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21624

From the chroot build log:

eccerr0r · Posted: Fri Aug 13, 2021 11:48 pm Post subject:

dammit just noticed that even the local build says "aes detected" which is very odd... unless the build logs were crossed...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

I tried to set :

Anon-E-moose · Posted: Sat Aug 14, 2021 12:35 am Post subject:

I'd probably patch CMakeLists.txt to remove these

include(CheckCCompilerFlag)
include(CheckCXXCompilerFlag)
include(CheckLinkerFlag)

as they are adding to the flags you already supply.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Hu · Moderator Joined: 06 Mar 2007 Posts: 21624

Perhaps -maes is not the problem? OP: what illegal instruction is used that causes the failure?

Anon-E-moose · Posted: Sat Aug 14, 2021 12:54 am Post subject:

eccerr0r · Posted: Sat Aug 14, 2021 1:01 am Post subject:

The -march=native in any case must be removed regardless of what's going on with -maes. I suspect that solving the removal of -march=native will also remove -maes.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

eccerr0r · Posted: Sat Aug 14, 2021 1:49 am Post subject:

Well, I guess it doesn't really matter what the faulting instruction is. With -march=native on a computer compiling that's not of the same architecture, it can generate bad instructions regardless if -maes is also put there.

I wouldn't be surprised if it put in aes instructions as it's probably doing encryption of sorts.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Anon-E-moose · Posted: Sat Aug 14, 2021 10:29 am Post subject:

eccerr0r · Posted: Sat Aug 14, 2021 1:43 pm Post subject:

Again I'm just a cmake n00b but my current guess if you apply this patch to the ebuild:

Anon-E-moose · Posted: Sat Aug 14, 2021 2:03 pm Post subject:

Good find

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

Anon-E-moose · Posted: Sat Aug 14, 2021 5:06 pm Post subject:

You could add it to the ebuild, but I'd do it by way of adding a USE flag so that it could be turned on and off without re-digesting the ebuild.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

eccerr0r · Posted: Sat Aug 14, 2021 6:02 pm Post subject:

I still see -maes which could be a problem, that looks weird... does it work even with -maes added?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Anon-E-moose · Posted: Sat Aug 14, 2021 6:14 pm Post subject:

eccerr0r · Posted: Sat Aug 14, 2021 7:14 pm Post subject:

correct, -DNO_AES=1 should disable the test and also -maes, but thought that ARCH=default should also automatically disable the test and -maes... apparently I was wrong, else something doesn't quite make sense here...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

sdauth · Guru Joined: 19 Sep 2018 Posts: 569 Location: Ásgarðr

eccerr0r · Posted: Sat Aug 14, 2021 8:02 pm Post subject:

Well in the compiler flags section it puts a superfluous -DNO_AES there but theres no -maes so this is actually the desired behavior, however, if it did not actually emit any aes instructions, then it doesn't matter. Maybe gcc couldn't figure out how to convert C to using the aes instructions *shrug*...

Well, at least it works so I guess it's a no-op...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?