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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 3CB0839450C2 for ; Wed, 6 Jan 2021 10:08:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3CB0839450C2 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-361-RSVZpZdrOPmqw9A5b7ByTg-1; Wed, 06 Jan 2021 05:08:03 -0500 X-MC-Unique: RSVZpZdrOPmqw9A5b7ByTg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E92CC801AAA; Wed, 6 Jan 2021 10:08:01 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-11.ams2.redhat.com [10.36.112.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4C63560BE2; Wed, 6 Jan 2021 10:08:01 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 106A7vXE903953 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 6 Jan 2021 11:07:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 106A7tff903952; Wed, 6 Jan 2021 11:07:55 +0100 Date: Wed, 6 Jan 2021 11:07:55 +0100 From: Jakub Jelinek To: Richard Biener Cc: Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Alexandre Oliva Subject: Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937) Message-ID: <20210106100755.GB725145@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 10:08:08 -0000 On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote: > > Theoretically we could exclude the range of the no-loc function > > from the .debug_ranges, then gdb would not even step into the function. > > I'd argue we're failing to emit a .endloc at the end of functions > (rather than issueing a .noloc at the start of functions with no > locations). I wonder if using a special file ID and switching to that > would be an effective workaround? When gas is extended we could use > file ID zero for this (which gas currently rejects). If we had .endloc, emitting it at the end of functions would be theoretically more correct, but I'd be afraid it would unnecessarily grow the .debug_line size, because nobody should care about line information in padding bytes between functions and the .endloc would add there a change even when it would affect just one byte of padding (probably even when it wouldn't affect anything, depending on how it is implemented). Jakub