From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2khNK8njY2OosBMAWB0awg (envelope-from ) for ; Thu, 03 Nov 2022 11:52:41 -0400 Received: by simark.ca (Postfix, from userid 112) id A54BC1E124; Thu, 3 Nov 2022 11:52:41 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=sbtjgbGV; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5B7611E11E for ; Thu, 3 Nov 2022 11:52:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F2E30385840B for ; Thu, 3 Nov 2022 15:52:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2E30385840B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667490761; bh=RQdrVevtEH34MhubP8/jZQ5H/uIT98fC0GBidw8yPAY=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=sbtjgbGVCPU5Yx8st45feGdnmFe905jSdxlNA0tbpVdinjomOpxaOjMFxrYBIfntj UwhS+IquQ0JiMElEfgGwK5zIztLUAJGyqOMbAhi1/iEfCwLHfV4ffJjupxjbRBpcie 9tTu2pWwFTLn0KUAWuGv2m1PIMXFXmc0uaodA0KQ= Received: from lndn.lancelotsix.com (vps-42846194.vps.ovh.net [IPv6:2001:41d0:801:2000::2400]) by sourceware.org (Postfix) with ESMTPS id DA97B3858D20 for ; Thu, 3 Nov 2022 15:52:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA97B3858D20 Received: from ubuntu.lan (unknown [IPv6:2a02:390:9086::635]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 8CE0180024; Thu, 3 Nov 2022 15:52:13 +0000 (UTC) Date: Thu, 3 Nov 2022 15:52:06 +0000 To: Kevin Buettner Subject: Re: [PATCH 1/2] Allow debugging of runtime loader / dynamic linker Message-ID: <20221103155128.uv3mpxhinsmfxulf@ubuntu.lan> References: <20221008035716.46147-1-kevinb@redhat.com> <20221008035716.46147-2-kevinb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221008035716.46147-2-kevinb@redhat.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Thu, 03 Nov 2022 15:52:13 +0000 (UTC) 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: , From: Lancelot SIX via Gdb-patches Reply-To: Lancelot SIX Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Kevin, We have recently encountered a bug with the master branch. Simon have opened https://sourceware.org/bugzilla/show_bug.cgi?id=29747 to track it. By running `git bisect`, it seems that this problem appeared with this patch. Do you think you would have time to investigate this issue? I have not looked at the actual problem yet. I have just been looking at when the regression got introduced. I do not expect it to be too long to fix, but I am not familiar with this part of the code. Please let me know if you do not have time to investigate this. Best, Lancelot. On Fri, Oct 07, 2022 at 08:57:15PM -0700, Kevin Buettner via Gdb-patches wrote: > At present, GDB does not allow for the debugging of the runtime loader > and/or dynamic linker. Much of the time, this makes sense. An > application programmer doesn't normally want to see symbol resolution > code when stepping into a function that hasn't been resolved yet. > > But someone who wishes to debug the runtime loader / dynamic linker > might place a breakpoint in that code and then wish to debug it > as normal. At the moment, this is not possible. Attempting to step > will cause GDB to internally step (and not stop) until code > unrelated to the dynamic linker is reached. > > This commit makes a minor change to infrun.c which allows the dynamic > loader / linker to be debugged in the case where a step, next, etc. > is initiated from within that code. > > While developing this fix, I tried some approaches which weren't quite > right. The GDB testusite definitely contains tests which FAIL when > it's done incorrectly. (At one point, I saw 17 regressions!) This > commit has been tested on x86-64 linux with no regressions. > --- > gdb/infrun.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 1957e8020dd..52441b7ab5c 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -6961,7 +6961,10 @@ process_event_stop_test (struct execution_control_state *ecs) > > if (execution_direction != EXEC_REVERSE > && ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE > - && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ())) > + && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ()) > + && !in_solib_dynsym_resolve_code ( > + ecs->event_thread->control.step_start_function->value_block () > + ->entry_pc ())) > { > CORE_ADDR pc_after_resolver = > gdbarch_skip_solib_resolver (gdbarch, ecs->event_thread->stop_pc ()); > -- > 2.37.3 >