From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4A9D13872554 for ; Wed, 14 Dec 2022 16:58:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A9D13872554 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671037122; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fQSYQA7oZLiW2ToZgX/w5VhW6mlZ4v/4u4NPnRBX7MM=; b=W+o7TZfPIjOZvvRrTKtRhrBUjQ7af2BRcJugogah+sWfKLlQfoA8Wwnk4dTJUoi8fyytCy WxDnkFuXFncGOsp92/a2v5FiJyRj4ZHgtGEhk4SNJ8QLU96zB54ovdh9EXXfi8nicV+uvW joaTAW+2y5RIsQYbeYOesBTQtgM84/s= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-86-o5Hbv2MyNFCjb6n8UirU2g-1; Wed, 14 Dec 2022 11:58:41 -0500 X-MC-Unique: o5Hbv2MyNFCjb6n8UirU2g-1 Received: by mail-wr1-f69.google.com with SMTP id e7-20020adf9bc7000000b00242121eebe2so95737wrc.3 for ; Wed, 14 Dec 2022 08:58:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fQSYQA7oZLiW2ToZgX/w5VhW6mlZ4v/4u4NPnRBX7MM=; b=W3SR3OdWTvmEKk64eeIi834G6X2eV/7klrw08HdN4D2hsz3Vac/Pls9zL4L/q9A5vY hcI1IhlVFtX9Er07xKbkp0xn1KiyqkhhJoNlMGruSu10Wp9S6y8ui4BKxYulVJ+RcBLF 7LfcPC3RYiRTlR32FjeViM1u0WOdg+3WJEO1N5qTzS9hUhs7/7sKC/no8g9QG7riHDRS VI9hYZWpoqG0EraamQ42/pMU4MgR1B9NqgMKF/Y6tp5WZNek4WZuQZjSNpGtKpqVRFdD 3Py36yTiHlsI+iHJh28lwbqKl+j4OCAq+vgXw7OcPV5n76TTDMfgIhAahmraQhtxcMcw q0LA== X-Gm-Message-State: ANoB5pn6G6TqqG8BroZL+lyINnNJxK9kKPBw6X1Eui5RY2dcl+g89ouF NR3rJh+QTvYgTb+sJ2YxurGiz4Ub7D8r2jUY+8liJuq4LiHnxPB4HdhZDBxbZx8xmq58aIvVG91 EI7r4V0hKGbyflTb3eA== X-Received: by 2002:adf:f802:0:b0:24b:b74d:8011 with SMTP id s2-20020adff802000000b0024bb74d8011mr15646368wrp.6.1671037119794; Wed, 14 Dec 2022 08:58:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf6I2azFlrJETNXzAGMPZEH3FsYBeiptrjaFtsT79kjB9fLoDNyTbyGwEJi6QMsDjlK8Lbh6Qw== X-Received: by 2002:adf:f802:0:b0:24b:b74d:8011 with SMTP id s2-20020adff802000000b0024bb74d8011mr15646350wrp.6.1671037119548; Wed, 14 Dec 2022 08:58:39 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id bt14-20020a056000080e00b00242257f2672sm3503746wrb.77.2022.12.14.08.58.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Dec 2022 08:58:39 -0800 (PST) From: Andrew Burgess To: Luis Machado , Jan Beulich , Binutils Cc: Nick Clifton , "ramana.radhakrishnan@arm.com" , Richard Earnshaw , Marcus Shawcroft , Alan Modra , Peter Bergner , Geoff Keating , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu , "H.J. Lu" Subject: Re: [PATCH v2 2/2] gas: re-work line number tracking for macros and their expansions In-Reply-To: <87edt20ycr.fsf@redhat.com> References: <1d528267-9450-12c7-4c4c-fe4deb3b0617@suse.com> <8eff1de6-871d-24cc-8804-9af7da0a86cf@suse.com> <87edt20ycr.fsf@redhat.com> Date: Wed, 14 Dec 2022 16:58:38 +0000 Message-ID: <87a63p2a81.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Andrew Burgess writes: > Luis Machado via Binutils writes: > >> Hi, >> >> I'm not yet sure how, but this patch has broken at least one gdb test (gdb.asm/asm-source.exp) for aarch64-linux (Ubuntu 22.04 and 20.04). >> >> Could you please take a look at it? I can do some testing with the aarch64 machines if that's helpful. >> >> FAIL: gdb.asm/asm-source.exp: f at main >> FAIL: gdb.asm/asm-source.exp: n at main >> FAIL: gdb.asm/asm-source.exp: next over macro >> FAIL: gdb.asm/asm-source.exp: list >> FAIL: gdb.asm/asm-source.exp: f in foo2 >> FAIL: gdb.asm/asm-source.exp: n in foo2 >> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2 >> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2 >> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3 >> FAIL: gdb.asm/asm-source.exp: finish from foo3 >> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s >> FAIL: gdb.asm/asm-source.exp: info line >> FAIL: gdb.asm/asm-source.exp: next over foo3 >> FAIL: gdb.asm/asm-source.exp: return from foo2 > > Can confirm I'm seeing the same set of failures on x86-64 gdb when using > gas that includes this patch. I think I understand the issue a little more now. I have a simple reproducer which can be run outside the gdb testsuite (see below). It appears that the DWARF for macros now tries to associate the instructions within the macro the source location within the macro definition, rather than the macro use site. I'm not entirely convinced this is a good idea (as a macro could be used multiple times), or even if this was an intended change of this series. If this is the direction gas is moving in then I guess we will need to update the GDB test, but there is, I think, a bug in the generated DWARF, in that it appears that the wrong file name is being used. Here's my steps to reproduce: $ cat test.s .include "other.inc" .global _start _start: xor %rbp, %rbp call main hlt .global main main: gdbasm_enter hlt $ cat other.inc .macro gdbasm_enter push %rbp mov %rsp,%rbp .endm $ cat Makefile all: $(AS) --gdwarf-2 -o test.o test.s $(LD) -o test test.o clean: -rm -f test.o test $ make AS=/path/to/recent/build/of/gas/as-new /path/to/recent/build/of/gas/as-new --gdwarf-2 -o test.o test.s ld -o test test.o $ cat cmd.gdb set height 0 set trace-commands on start frame $ gdb -q -x cmd.gdb test Reading symbols from test... +start Temporary breakpoint 1 at 0x401009: file test.s, line 2. Temporary breakpoint 1, main () at test.s:2 2 +frame #0 main () at test.s:2 2 (gdb) Notice that when we stopped at 'main' in gdb the location was reported as test.s:2. The '2' here is correctly indicating line 2, but the file should be 'other.inc', not 'test.s'. If I rebuild using an older version of gas, then repeat the gdb step, the old behaviour was: $ make as --gdwarf-2 -o test.o test.s ld -o test test.o $ gdb -q -x cmd.gdb test Reading symbols from test... +start Temporary breakpoint 1 at 0x401009: file test.s, line 11. Temporary breakpoint 1, main () at test.s:11 11 gdbasm_enter +frame #0 main () at test.s:11 11 gdbasm_enter (gdb) Now the location is 'test.s:11', pointing at the macro invocation. To me, this seems more helpful, but that's just my $0.02 worth. As a separate idea from the above, I wonder if we could have gas generate the DWARF required to represent the macro expansion as an inlined function. This might solve the problem of whether the DWARF should point at the location of the macro definition, or the macro invocation... Anyway, hopefully the reproducer helps track down the problem. Thanks, Andrew