From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 29506382FE5C for ; Thu, 9 Jun 2022 18:25:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29506382FE5C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id x6-20020a1c7c06000000b003972dfca96cso1647wmc.4 for ; Thu, 09 Jun 2022 11:25:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Y2WfXWpLVYGEkKlLwXIV11DLG67ZcJOt6HkPyHb1hqI=; b=xSJH6wb8lVUD8D+uEY6xzmhvjA+cJCZNywtB5VUxmfC5aE6YEk0W7vBN0C9ZtHuIMm Kb1baHB0s39wjHVd5u9ENzS7H6DxD21r5rWP77km8UlhexwvTtQzNPRnZ8gE/7XrarQs hpNmppYbsflCE0t4FfOEeheS4woSUr73VlENSAz4B7ri5LPuKLCK8rlWAeiA2P77j0Ef vYEf2aIz1Wu30qqv/fPQnWQUk/zCr6Sr53kdIgxyYIntIK7k29YGTLOxOIZHgoAv/aLw DOmXkBlGIUrGt+tN9X19FTP/FNBQG47WGF/0uYQVoj2LyASVwG83ST76hBQq9u4M6rt0 PPQw== X-Gm-Message-State: AOAM532DoXifefOFXy7zqm7tlnEzYb0aNzid9p9/Kcjz/e9CIsB7Dypk Xj00B4St7BTgY/VnCZsoqc0jz+O0H/Z28A== X-Google-Smtp-Source: ABdhPJzeGWLr8uKnmWFATPfpe8Ewtg2Hoy5QxZBgR8x2Oh6tmLGyE54U24+06/XDnpNehVp8w3EynA== X-Received: by 2002:a05:600c:4e51:b0:39c:4f18:4c29 with SMTP id e17-20020a05600c4e5100b0039c4f184c29mr4739433wmq.101.1654799120950; Thu, 09 Jun 2022 11:25:20 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id n30-20020a05600c501e00b0039bc95cf4b2sm43194wmr.11.2022.06.09.11.25.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jun 2022 11:25:19 -0700 (PDT) Message-ID: Date: Thu, 9 Jun 2022 19:25:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v3 02/14] Change gdb.base/skip-solib.exp deal with lack of epilogue information Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <20220526151041.23223-1-blarsen@redhat.com> <20220526151041.23223-3-blarsen@redhat.com> <23a15847-a4f5-d25b-3477-a03b5942eb21@redhat.com> From: Pedro Alves In-Reply-To: <23a15847-a4f5-d25b-3477-a03b5942eb21@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 18:25:24 -0000 On 2022-06-09 17:27, Bruno Larsen wrote: > > On 6/8/22 12:37, Pedro Alves wrote: >> On 2022-05-26 16:10, Bruno Larsen via Gdb-patches wrote: >>> When running gdb.base/skip-solib.exp, the backtrace tests could fail if >>> the compiler did not emit epilogue information for trivial epilogues, >> >> I found "emit epilogue information" very confusing FWIW.  When I read that the first time, >> I thought this was talking about unwind info for the prologue after the stack is destroyed, >> and I wondered why not fix clang instead. >> >> I think the following would be more accurate: >> >>   "fail with compilers that associate prologue insns with the function's last >>    statement line instead of the function's closing brace". > > Yeah, I think this is a better explanation, but s/prologue/epilogue, right? Right. That was a typo. I meant: "fail with compilers that associate epilogue insns with the function's last statement line instead of the function's closing brace". > I tried to make this concept more specific by saying that clang doesn't emit epilogue information, Have I misunderstood or misnamed it? To me "epilogue information" sounds like some special DWARF information specific to epilogues. It reminds of me of special epilogue unwinders that GDB has, like amd64_epilogue_frame_unwind, i386_epilogue_frame_unwind, rs6000_epilogue_frame_unwind, etc. By not saying "line" anywhere, I have nothing to connect "epilogue information" to "line info". Once you make the connection, you understand that there's nothing special about "epilogue information", it's just that clang and gcc choose different lines numbers for the epilogue instructions. >>> diff --git a/gdb/testsuite/gdb.base/skip-inline.exp b/gdb/testsuite/gdb.base/skip-inline.exp >>> index f6e9926b66c..327ea676140 100644 >>> --- a/gdb/testsuite/gdb.base/skip-inline.exp >>> +++ b/gdb/testsuite/gdb.base/skip-inline.exp >>> @@ -35,16 +35,20 @@ gdb_test "skip function foo" "Function foo will be skipped when stepping\." >>>   gdb_test "bt" "\\s*\\#0\\s+main.*" "in the main" >>>   gdb_test "step" ".*" "step into baz, since foo will be skipped" >>>   gdb_test "bt" "\\s*\\#0\\s+baz.*" "in the baz, since foo was skipped" >>> -gdb_test "step" ".*" "step in the baz" >>> -gdb_test "bt" "\\s*\\#0\\s+baz.*" "still in the baz" >>> -gdb_test "step" ".*" "step back to main" >>> +gdb_step_until_regexp ".*x = 0; x = baz \\(foo \\(\\)\\).*" >> >> FWIW, I'd remove the "regexp" from the function's name, just call it gdb_step_until. > > Alright, but this sounds more like a review of the first patch than this one. It only stood out to me when I saw it in use, as in the function name is long and regexp stuck out like a sore thumb here. :-) >> Or even with a simple "just main" program, like so: >> >>   (gdb) list >>   1       int >>   2       main () >>   3       { >>   4         return 0; >>   5       } >> >> we get this with gcc: >> >>   (gdb) info line 4 >>   Line 4 of "main.c" starts at address 0x1131 and ends at 0x1136 . >>   (gdb) info line 5 >>   Line 5 of "main.c" starts at address 0x1136 and ends at 0x1138. >>   (gdb) >> >> and this with clang: >> >>   (gdb) info line 4 >>   Line 4 of "main.c" starts at address 0x40111d and ends at 0x40111f. >>   (gdb) info line 5 >>   Line number 5 is out of range for "main.c". >>   (gdb) >> >> I think that we can use that to write a caching proc like: >> >>   # Return true if the compiler emits line information associating prologue insns with >>   # the function's closing brace.  Return false if not, meaning the prologue >>   # associates prologue instructions with function's last line with a statement. >> >>   gdb_caching_proc have_prologue_line_info { >>       use gdb_simple_compile the simple main program from above >>             use "info line 5", and return false if we get "out of range", otherwise return true. >>   } >> > > This sounds like a good idea, I would only change the default behavior to returning false, unless we saw specifically "start at address.*and ends at". ... > This would make GDB changes more pronounced, as GCC would start having different results. Note sure what you mean here.