mingw32_386-msvcrt_win95-16 gdb.exe includes Pentium instructions

[Jookia]

After building the correct branch and profile I get a 'mingw32_386-msvcrt_win95-16.1.0-r0.1.tar.zst' file. Extracting this I get a gdb.exe file. Copying it to a target with an i386 or i486 CPU it fails. objdump shows gdb.exe contains i586 instructions:

  f33453:       0f a2                   cpuid
  f33455:       81 e3 00 00 04 00       and    $0x40000,%ebx
  f3345b:       75 79                   jne    0xf334d6
  f3345d:       e9 ce 00 00 00          jmp    0xf33530
  f33462:       8d b6 00 00 00 00       lea    0x0(%esi),%esi
  f33468:       8b 02                   mov    (%edx),%eax
  f3346a:       81 38 64 65 66 61       cmpl   $0x61666564,(%eax)
  f33470:       0f 84 8a 00 00 00       je     0xf33500
  f33476:       89 1c 24                mov    %ebx,(%esp)
  f33479:       e9 16 36 07 00          jmp    0xfa6a94
  f3347e:       66 90                   xchg   %ax,%ax

Also present are cmov which is 686 instructions, meaning it probably wouldn't work on 586 either.
I will do some investigating to try and figure out why this is happening.

[Jookia]

Hmm. The AAB and ABB ./lib/libstdc++.a has these instructions too.

[Jookia]

Here's a quick test snippet of code:

int main(int argc, char **argv) {
	if (argc < 5)
		argc = 0;
	argv[argc] = 0;
	return 0;
}

With -Os this compiles to use 'cmovle' using the mingw-lite (and mingw-w64 built with crosstool). -mcpu doesn't really do anything, only -march.

config.log says this:

target_cpu='i686'
target_noncanonical='i686-w64-mingw32'
target_os='mingw32'
target_subdir='i686-w64-mingw32'
target_vendor='w64'
tooldir='${exec_prefix}/i686-w64-mingw32'

I did some delving in to GCC's code and it looks like with-arch does nothing on x86. target_cpu is derived specifically from the toolchain name, which in this case is i686-.

[CyanoHao]

objdump shows gdb.exe contains i586 instructions:

This part came from std::random_device::_M_init. They are not checking CPUID availability before using it...
(https://github.com/gcc-mirror/gcc/blob/releases/gcc-16.1.0/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc)

[Jookia]

That's not great. Maybe the solution is to name it i386-w64-mingw32 ? crosstool seems to generate i386-compatible code if you do that

[Jookia]

Okay, I was wrong, there is no specific problem with code generation. crosstool-ng isn't setting the arch properly but mingw-lite is. You're correct that it's only from random_device. I've fixed it on my local build, I will send a PR tomorrow to disable RDRAND/RDSEED.

[Jookia]

I'm giving a little update on this: I'll be sumitting a PR soon that fixes this, the issue isn't actually in GCC as it uses __get_cpuid_max(0, &ebx) to gate the CPUID check. The problem is in Python's mi_detect_cpu_features. I've opened PR to fix this by adding a check for cpuid.

As another note, building with GCC 13 gives an 'mfence' instruction in GDB. I tracked it down to libpythoncore.a , Python 3.12 seems to output mfence unconditionally: https://github.com/python/cpython/blob/3.12/Include/internal/pycore_atomic.h#L131C1-L131C24

Building with GCC 14 gives a 'Python not initialized' errors for GDB.

I'm not too interested in using these older compilers, so I'm not going to do anything about them.