From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B6687385771C; Mon, 6 Nov 2023 15:42:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6687385771C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1699285357; bh=WKHzJbV/t3k2pSGFuVdUnnnMHOpFTGXFc7nWmiW8SSc=; h=From:To:Subject:Date:From; b=xomICc0BRqFMQJi3IJCgABtaO4AOO9E3u0QbGczVaXcMhQn1yRavsi5JzxH10aAy7 JOoWVo0BUAwley7MyA1k1E+uEExu3iTn0szdvGEExQrvgiexL1AmsgOiR3sE4U/820 RK32IyaX2mCq6d6+wu4+mwUJAKkvnnZmi5k0KImg= From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug d/112408] New: [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone Date: Mon, 06 Nov 2023 15:42:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: d X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ibuclaw at gdcproject dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone cf_gcchost cf_gcctarget cf_gccbuild Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112408 Bug ID: 112408 Summary: [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11, x86_64-pc-linux-gnu Target: i386-pc-solaris2.11, x86_64-pc-linux-gnu Build: i386-pc-solaris2.11, x86_64-pc-linux-gnu While preparing GCC builds for a new Solaris 11.4/x86 GCC CFarm system, I re-ran into an issue with D programs looping inside a Solaris kernel zone (a VM), while the same binaries work fine on bare metal. I've now managed to root-cause the issue. When bootstrapping e.g. GCC 13 w= ith GCC 9.5.0 or 11.4.0, configuring libphobos in stage 1 loops. This can be reproduced with $ cat conftest.d module object; extern(C) int main() { return 0; } $ d21 conftest.d which loops indefinitely. d21 show the following stacktrace: Thread 2 received signal SIGINT, Interrupt. [Switching to Thread 1 (LWP 1)] _D4core5cpuid12getCpuInfo0BFNbNiNeZv () at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669 669 if (b!=3D0) { 1: x/i $pc =3D> 0x442b311 <_D4core5cpuid12getCpuInfo0BFNbNiNeZv+33>: test %ebx,%= ebx (gdb) bt #0 _D4core5cpuid12getCpuInfo0BFNbNiNeZv () at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669 #1 0x000000000442b7e3 in _D4core5cpuid8cpuidX86FNbNiNeZv () at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:953 #2 0x000000000442bd75 in _D4core5cpuid18_sharedStaticCtor1FNbNiNeZv () at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:1073 #3 0x000000000441a421 in runModuleFuncs (this=3D0x0, modules=3D...) at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:858 #4 _D2rt5minfo11ModuleGroup8runCtorsMFZv (this=3D...) at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:728 #5 0x000000000441b5bd in __foreachbody1 (this=3D, sg=3D...) at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:796 #6 0x000000000440ffd2 in _D3gcc8sections3elf3DSO7opApplyFMDFKSQBjQBiQBcQBb= ZiZi (dg=3D...) at gcc-11.4.0/libphobos/libdruntime/gcc/sections/elf.d:106 #7 0x000000000441a61e in rt_moduleCtor () at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:793 #8 0x000000000440f880 in rt_init () at gcc-11.4.0/libphobos/libdruntime/rt/dmain2.d:129 #9 0x00000000022f4c16 in d_init_options (decoded_options=3D0x47e1f00) at gcc-13.2.0/gcc/d/d-lang.cc:290 #10 0x0000000002ac5fbc in toplev::main (this=3D0x7fffbffff97a, argc=3D2,=20 argv=3D0x7fffbffff9b8) at gcc-13.2.0/gcc/toplev.cc:2240 #11 0x0000000004301c46 in main (argc=3D2, argv=3D0x7fffbffff9b8) at gcc-13.2.0/gcc/main.cc:39 Running getCpuInfo0B side-by-side in the kernel zone and on bare metal show= s: kernel zone bare metal level 0 a 0 1 b 1 2 level 1 a 0 5 b 1 28 level 2 a 0 0 b 1 0 and so on for each higher level. So inside a kernel zone, a!=3D0 || b!=3D0= remains true, explaining the loop. If I'm reading the spec (Intel=C2=AE 64 and IA-32 Architectures Software Developer=E2=80=99s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3= A, 3B, 3C, 3D, and 4, Order Number: 325462-081US, September 2023, Vol. 2A, 3-225, p.821) correctly, this is a bug in the kernel zone software: A sub-leaf returning an invalid domain always returns 0 in EAX and EBX. OTOH I don't see why getCpuInfo0B needs to loop here since it's only intere= sted in levels 0 and 1 anyway. This affects all DMD-based versions of GDC, while the previous C++-based versions are fine.=