From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B1ACB3939C35; Tue, 23 Jun 2020 11:45:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1ACB3939C35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592912711; bh=2Qn2JmWKSR3PTl74FDDxs7q30j9foEFeePn34eOw4Bs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LhGdQAZL68RfHh30HXco/8aLjrBlFTj5YX/01r7gPRSPgU6SaHBod5n+t59dk2YBy ggqVmhdgTIzjGUJ5ks32iL4NGrjDDgpPNaRZSB5wxW2OP4SYDy71x2hq3WUqbTiSHL u3rVX7aJwhjPbtPeluzmfHdonLeVL3jiq06jtGM0= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin Date: Tue, 23 Jun 2020 11:45:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: aoliva at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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, 23 Jun 2020 11:45:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95577 --- Comment #4 from Iain Sandoe --- (In reply to Alexandre Oliva from comment #3) > Iain, >=20 > Do platforms that use dsymutil support -gsplit-dwarf? None I am aware of - Darwin should reject -gsplit-dwarf with a diagnostic, = so that configuration should detect missing support correctly there. > I'm thinking of bringing -g into the gsplit_dwarf variable, so it won't be > enable without -gsplit-dwarf, and removing other explicit mentions of -g > from outputs.exp. >=20 > Would this be enough to address the dsymutil left-overs? I don't think so (hence the code to detect -g* and delete the .dSYM if one = is seen). =3D=3D=3D=3D=3D=3D The motivation for Darwin's 'split' debug is actually different from the -gsplit-dwarf (and it doesn't solve the object size problem that split dwarf does). For the record - the Darwin behaviour is like this; [when debug is enabled] the static linker [ld64] embeds a list of contribut= ing object file paths into the executable. It does not link or include any deb= ug in the exe (this saves time). dsymutil [the debug linker] takes the executable, looks up the list of obje= ct files and produces a linked debug object, this is placed into a Darwin file package (a directory structure with some metadata embedded + the object). = This is named .dSYM <=3D but it's a file package, so has to be deleted like= a directory. On Darwin, debug consumers have two options; 1. Use the table in the exe to pull the debug data directly from the contributing objects (i.e. never do an actual debug link but just dynamical= ly satisfy those symbols the user inspects). - LLDB and GDB both grok this (newer GDBs might have bit-rotted somewhat since Adacore is no longer maintaining the Darwin binutils stuff and I am totally out of cycles to contribute). 2. If the the debug linker has been run and the .dSYM is available, they can use that. 1) is very efficient for large projects with many object files with long de= bug link times, since that stage of linking can be omitted in the compile/edit/debug loop. ----- BUT, then there's one case where (1) doesn't work - which is when the user does; gcc foo.c bar.o ..... -g -o x because the object file created for any source on the command line is ephemeral, and thus if it's put into the exe that doesn't help - because it won't be available at debug time. So Darwin's linker spec force dsymutil to be run for any compile line that includes a source file, this is a very common circumstance in the test suit= e, leading to many .dSYM files that need to be removed. The patch fragment at comment #1 addresses this for these tests (and Dominq= ue has a larger patch [which I need to look at] to clean it up in more places = in the test suite).=