From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by sourceware.org (Postfix) with ESMTPS id 6B4453857012 for ; Fri, 5 Mar 2021 00:06:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6B4453857012 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: (qmail 47368 invoked from network); 5 Mar 2021 00:06:53 -0000 X-APM-Out-ID: 16149028124736 X-APM-Authkey: 257869/1(257869/1) 2 Received: from unknown (HELO ?192.168.1.212?) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 5 Mar 2021 00:06:53 -0000 Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: DWARF debug info version on macOS and 'std::' namespace (and pretty-printers) From: Iain Sandoe In-Reply-To: Date: Fri, 5 Mar 2021 00:06:52 +0000 Cc: libstdc++@gcc.gnu.org Content-Transfer-Encoding: 8bit Message-Id: References: To: Philippe Blain X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 00:06:57 -0000 Philippe Blain wrote: > I'm trying to understand why a 'std::vector' appears in GDB as > 'type = vector >' instead of > 'std::vector<…>’ I can’t help much with the body of this report (how the debug info relates to what’s presented) .. hopefully someone more familiar with what is representable by each version of debug info can chime in ... but... > Incidentally, it seems that defaulting to DWARF-2 on macOS is a decision > taken in 2009 > (stemming from 047a3193bd729475182a438d9929ec923f484481, From-SVN: > r152127 [2]) > and I'm wondering if it's still the best thing to do ? … This something under review at the moment. The majority of macOS users are using the assembler, linker and debug linker (dsymutil) from some installed version of Xcode. So that means that whatever DWARF is emitted by GCC has to be compatible with those tools; it takes quite some time to evaluate this for the versions of system and xcode out there (we had numerous issues especially with the tools based on dwarfutils whenever trying to move to > dwarf 2 - recently I revaluated this because we would like DWARF-3 to support D - and it’s still not viable on many system versions). I am hopeful that we will be able to switch to default of DWARF-4 for macOS versions >= 10.10 sometime in GCC12 (it might be that we have to check for suitable support from dsymutil, and I have some patches for that to apply in next stage #1). You say you’re using 10.11.6 and 10.15.7, and I’m assuming you have XCode command line tools (or App) >= 7.2 installed. In that case, it’s probable that you will have good results from using -gdwarf-4 ( I guess if it’s iritating enough to have to do that, you could always change the default and rebuild the compiler ;) ). FWIW, in general, I find that debugging complex C++ (e.g. the compilers) works pretty well with default settings and -O0 -g on macOS 10.12 and higher (but mostly using lldb as the debugger). Iain