From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 54327385ED4B for ; Sun, 30 Aug 2020 17:18:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 54327385ED4B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 066AE30278CD for ; Sun, 30 Aug 2020 19:18:51 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id B6EC0403F6E7; Sun, 30 Aug 2020 19:18:51 +0200 (CEST) Message-ID: Subject: DWARF5 and .gdb_index/.debug_names From: Mark Wielaard To: gdb@sourceware.org Date: Sun, 30 Aug 2020 19:18:51 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, 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: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 17:18:55 -0000 Hi, Last week we had a DWARF BoF at the virtual GNU tools cauldron. Notes have been posted to the gcc wiki: https://gcc.gnu.org/wiki/LPC2020NotesDWARF I would like to try to make DWARF5 the default for GCC11 and have been trying to fix any issues I could find. Testing gdb went pretty well. There is one issue that I originally filed against gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=3D26525 But that is most likely a bug in gcc. Jakub has a patch that fixes the issue for gcc, but there is some debate whether that is the correct approach or not: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552535.html Note that I haven't really looked for issues in languages other than C or C++, so someone might want to double check whether other languages supported by gcc are also ready to switch to DWARF5 by default. During the BoF Pedro mentioned that the GDB DWARF5 .debug_names support is incomplete/wrong. I was wondering whether there was a good description of the issue and/or a bug report for it. When using the contrib/gdb-add-index.sh it does add a .gdb_index for objects containing DWARF5 and the results seem correct, gdb also seems to be able to use it. When adding -dwarf-5 it seems to output a .debug_names section which can be read by binutils readelf (elfutils doesn't yet support .debug_names). I couldn't immediately see in what way it was wrong/incomplete. dwz does support .gdb_index rewriting, but doesn't know about .debug_names yet. So could we as a first step, when switching the DWARF5 keep using .gdb_index? At least till any issues with gdb .debug_names are resolved and dwz supports it? Thanks, Mark