From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9L06B3y31Gbf5BwAWB0awg (envelope-from ) for ; Sun, 01 Sep 2024 14:50:36 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=A7Uq2ozW; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 019521E353; Sun, 1 Sep 2024 14:50:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1D8931E08F for ; Sun, 1 Sep 2024 14:50:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8ADC3385EC0D for ; Sun, 1 Sep 2024 18:50:34 +0000 (GMT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id 9CAC13858404 for ; Sun, 1 Sep 2024 18:50:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CAC13858404 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9CAC13858404 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::232 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725216614; cv=none; b=w+S/POpdESNBNH1wXABt6VNM/j6WUVHFGZxp04jmbd1a3NQ9QRyE5MJFKJrbZsQDiZkcye+fFoa4tHhHXGzWKQGHdS651BA58cHtYeWc4ZDgQPSpvyEB8gU3swCzB2dFgkXE573w1rvKBeNgep8ddFS0jEGJ+xZIFVd+HewrXoI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725216614; c=relaxed/simple; bh=hAZj2OJrG77kjR/ageZk8VTVXBf6mvFyhgC5JEH0ufQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=MkZ716g8o/6RMFEYXfsxGOQMcuKQqTHnX+alFHrRLN66D0cviwmXry2N01lBqwAqKf45NciTGptxLAgF729teCl5coWCdR4GPu5MB6Zamnbi7uV1SNTyZnvDel0wx52CRX7F0XpoKz2TVDYf8rUFJeaCAY7OwGI52aVgXdyRTr4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3df16ece2c2so1252101b6e.2 for ; Sun, 01 Sep 2024 11:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1725216612; x=1725821412; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/NnKBsbjzL1+ClsoGlUjkl3ZM7tS/qKFnlboBbpeQdw=; b=A7Uq2ozWjW/faYJFnDK1dGcOV6/U9NVzdH4DDALefnKmXPWQl/IW6u1iDHpQUdj/ni CnVO0ZuVkrk4gA8NLToEEcj8eFevhrIn4bwxMMznGpiREneDCIL/wZwUOdCtlSXCax+F FRUa76gf+BZO/ZLv+itclT508O1UFrVTDZTjRKy5ij8KpUHCvQfWhI0ZF/68jgPpiUEk GQR3PpXrtmuut0NAnD8V9ui8eTMKCBUFMfn+wDs8UeSehG48suFXe9QXPon+MP++XLBz r+ITLlCTVrsHfSa1GZdTGT/URjR7IUhbT6Xu7u9QPAUxWrtR1wWRewA3oUZeY3m04F6o Zt0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725216612; x=1725821412; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/NnKBsbjzL1+ClsoGlUjkl3ZM7tS/qKFnlboBbpeQdw=; b=kDH4oVbsVRl8dLdtT4QOMBfKb1JSMDYGngjcREvFjhLUKIFJ/+jdIfzmV67n2MXLKQ H+Py7RrCoIOqOumDJN1sGYd50KS/CKD/cFNdzSQhBjE55FZmE764ogqfR36FQojNwPhK 1cE7Mb4NZuOctvLdEpPNBphrJIHcgMd2UfTYw/El9mTTzBooOBCNR8wc7WSZihmuvrWP VroArvEskcP6qkrxCaalcJ3OFKPnGu/4Hczgh+toqGkvUPxhwXY9H8MiM5XfyfpInd7y P7+L6Rz+58jw1K98Z/uIWJfrFXH/Li9q1zL3LxqKlA77T687UvmHMjyssRw4DHcr3ep7 VgEQ== X-Gm-Message-State: AOJu0Yw0oBqRt5l6CJlizzuj6hpMfgQWPURRuM5Y0E68086HV1dC0brK 6EHJmYJToo5U0MYPvuzeOe+NGAzknRlPkJ1A8OtOcOJC5tHItac1D21RW553 X-Google-Smtp-Source: AGHT+IGyKJVg5SU78oVkW9l0y1T+Ey+bJg80bLVbwNx7tvmjnbEg2ZFTPzMjBgBSHvKJjqv9TaqJAw== X-Received: by 2002:a05:6808:11c5:b0:3dc:39e9:e04 with SMTP id 5614622812f47-3df22106d0fmr4880200b6e.20.1725216611762; Sun, 01 Sep 2024 11:50:11 -0700 (PDT) Received: from takamaka.gnat.com ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2051553444fsm54833835ad.148.2024.09.01.11.50.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Sep 2024 11:50:11 -0700 (PDT) Received: by takamaka.gnat.com (Postfix, from userid 1000) id 3E5C280947; Sun, 1 Sep 2024 11:50:10 -0700 (PDT) Date: Sun, 1 Sep 2024 11:50:10 -0700 From: Joel Brobecker To: Dmitry Neverov , tom@tromey.com Cc: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [PR 31727] Recognize -2 as a tombstone value in .debug_line Message-ID: References: <20240608084529.1406412-1-dmitry.neverov@jetbrains.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240608084529.1406412-1-dmitry.neverov@jetbrains.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi everyone, I think this patch would be safe to apply to the gdb-15-branch, wouldn't it? I don't think the patch itself is critical per se, but having it in the GDB 15.2 release could be helpful to avoid what looked like a GDB 15.1 regression which turned out to be caused by a faulty stub. This is documented in... https://sourceware.org/bugzilla/show_bug.cgi?id=31801 ... and that PR has been on our list of PRs to fix for GDB 15 due to the apparent regression aspect. However, the current conclusion for 31801 is that there is no fix to do in GDB. The reason why this seemingly unrelated patch below would be helpful in the context above is that, apparently, the patch below indirectly hides the issue by making GDB's code going through a different code path. Two birds in one stone. OK for Dmitry to backport this patch to gdb-15-branch? Thank you, On Sat, Jun 08, 2024 at 10:45:29AM +0200, Dmitry Neverov wrote: > Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone > value -1 used by lld (https://reviews.llvm.org/D81784). The > referenced lld commit also uses the tombstone value -2 for > pre-DWARF-v5 > (https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7). > > If not handled, -2 breaks the pc step range calculation and triggers > the assertion: > > gdb/infrun.c:2794: internal-error: resume_1: Assertion > `pc_in_thread_step_range (pc, tp)' failed. > > This commit adds -2 tombstone value and handles it in the same way as -1. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727 > --- > gdb/dwarf2/read.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 6a19064409c..d720f58c8b4 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -17897,8 +17897,8 @@ class lnp_state_machine > we're processing the end of a sequence. */ > void record_line (bool end_sequence); > > - /* Check ADDRESS is -1, or zero and less than UNRELOCATED_LOWPC, and if true > - nop-out rest of the lines in this sequence. */ > + /* Check ADDRESS is -1, -2, or zero and less than UNRELOCATED_LOWPC, and if > + true nop-out rest of the lines in this sequence. */ > void check_line_address (struct dwarf2_cu *cu, > const gdb_byte *line_ptr, > unrelocated_addr unrelocated_lowpc, > @@ -18308,13 +18308,16 @@ lnp_state_machine::check_line_address (struct dwarf2_cu *cu, > unrelocated_addr unrelocated_lowpc, > unrelocated_addr address) > { > - /* Linkers resolve a symbolic relocation referencing a GC'd function to 0 or > - -1. If ADDRESS is 0, ignoring the opcode will err if the text section is > + /* Linkers resolve a symbolic relocation referencing a GC'd function to 0, > + -1 or -2 (-2 is used by certain lld versions, see > + https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7). > + If ADDRESS is 0, ignoring the opcode will err if the text section is > located at 0x0. In this case, additionally check that if > ADDRESS < UNRELOCATED_LOWPC. */ > > if ((address == (unrelocated_addr) 0 && address < unrelocated_lowpc) > - || address == (unrelocated_addr) -1) > + || address == (unrelocated_addr) -1 > + || address == (unrelocated_addr) -2) > { > /* This line table is for a function which has been > GCd by the linker. Ignore it. PR gdb/12528 */ > -- > 2.45.1 > -- Joel