From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A65093858402; Tue, 14 Sep 2021 10:15:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A65093858402 From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC Date: Tue, 14 Sep 2021 10:15:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: modula2 X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: everconfirmed cf_reconfirmed_on bug_status Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 10:15:19 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101392 Rainer Orth changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2021-09-14 Status|UNCONFIRMED |NEW --- Comment #1 from Rainer Orth --- (In reply to Rainer Orth from comment #0) > I couldn't make much sense of this yet. Probably requires rebuilding cc1= gm2 > with > -g3 -O0. I've now done just that. Here's what I find: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb51bb0 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfeb51bb0 in strlen () from /lib/libc.so.1 #1 0xfeb937fc in strdup () from /lib/libc.so.1 #2 0x02a48c90 in lrealpath (filename=3D0x0) at /vol/gcc/src/git/modula-2/libiberty/lrealpath.c:88 #3 0x02a45fa4 in canonical_filename_eq (a=3D0xffbff8e2 "SYSTEM.s", b=3D0x0) at /vol/gcc/src/git/modula-2/libiberty/filename_cmp.c:216 #4 0x016e97c8 in init_asm_output (name=3D0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 #5 0x016ed1dc in lang_dependent_init (name=3D0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2= 218 #7 0x016ee4a8 in toplev::main (this=3D0xffbff6e2, argc=3D7, argv=3D0xffbff= 74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 #8 0x02924ec4 in main (argc=3D7, argv=3D0xffbff74c) at /vol/gcc/src/git/modula-2/gcc/main.c:39 #4 0x016e97c8 in init_asm_output (name=3D0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:714 714 else if (!canonical_filename_eq (asm_file_name, name) (gdb) p asm_file_name $3 =3D 0xffbff8e2 "SYSTEM.s" (gdb) p name $4 =3D 0x0 (gdb) up #5 0x016ed1dc in lang_dependent_init (name=3D0x0) at /vol/gcc/src/git/modula-2/gcc/toplev.c:1927 1927 init_asm_output (name); gdb) up #6 0x016edf58 in do_compile () at /vol/gcc/src/git/modula-2/gcc/toplev.c:2= 218 2218 if (lang_dependent_init (main_input_filename)) (gdb) p main_input_filename $6 =3D 0x0 (gdb) up #7 0x016ee4a8 in toplev::main (this=3D0xffbff6e2, argc=3D7, argv=3D0xffbff= 74c) at /vol/gcc/src/git/modula-2/gcc/toplev.c:2372 2372 do_compile (); Ultimately, the problem is two-fold: * cc1gm2 doesn't set main_input_filename (perhaps only with -fdump-system-exports, I haven't checked) * In the end, libiberty's lrealpath is called with lrealpath (NULL, NULL) which again calls strdup (NULL), leading to the SEGV. I couldn't find a clear indication if this is supported by the C standard, but even if I ha= rden lrealpath to avoid strdup(NULL), I get more SEGVs later on in other place= s. So clearly the error is not setting main_input_filename. No idea why this happens for gm2 only or how to fix this, though.=