From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 4CA523858C98 for ; Mon, 26 Feb 2024 22:41:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CA523858C98 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4CA523858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708987314; cv=none; b=if3+o5jNLUfjKfSw95q4/JJfCfHHg4TJE+o109pFJV+sMzoNZebtBAlWJLaZiVv7o+26peu4q/kP19cCPm/SnHFC2r3WtzJjGL7vUT5KeSd+9S/5lbdZxHsc3j3AG9JqeYMu1LWjpNHNMJpraXeY6/Fot9BhbVn/YctzeMAH/qk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708987314; c=relaxed/simple; bh=X/w3V6Jg8dJJFz1/FVRjcuQdtcCKyDn1Wa2WRp2u9DU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kuRfJaaGDaIqYT4YDb3/K+Ly7qlDfLtpPjqPkNUaJGCm9G+Sk5qrwT8u3Uto5w/mm1isbvWPXrUfbcbYUytdGBfWaMNx/X2f/JuLfPJWTWiHFghJMqnNSj/ovmJdnJUyae81sZflvwLJYSr7R2EJwqT/UBad11D/AgCR8mSJTjM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1708987312; bh=X/w3V6Jg8dJJFz1/FVRjcuQdtcCKyDn1Wa2WRp2u9DU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ChubVbuNGzXvU5flNLy5S4BRlFV3Tiae6NPwHTkK7M2BibSo1gLXELGPdJYXndoUh DkEzPN2vZWSwUZ4Wzarcm3R2+SQqKrlQpSWGOnmD+hSW1VQkT0c6M2gWmWb7m50ZoD MYZWaoS/UPhsjLVpz0C+5NbVKStk/8T51DN+q8MQ= Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 808421E030; Mon, 26 Feb 2024 17:41:52 -0500 (EST) Message-ID: <38d9df8e-75f0-4a28-833c-06429ab94ccd@simark.ca> Date: Mon, 26 Feb 2024 17:41:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] [gdb] Fix "value is not available" with debug frame To: Thiago Jung Bauermann , Tom de Vries Cc: Kevin Buettner , Luis Machado , gdb-patches@sourceware.org References: <20240213171718.8934-1-tdevries@suse.de> <20240217210947.20211db0@f39-zbm-amd> <60882190-1fd7-45fc-a19b-661c027df154@suse.de> <877ciqg8it.fsf@linaro.org> Content-Language: fr From: Simon Marchi In-Reply-To: <877ciqg8it.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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 List-Id: On 2/26/24 17:34, Thiago Jung Bauermann wrote: > > Tom de Vries writes: >> This doesn't depend on debug info. The test-case depends on a register being unavailable. >> I don't know if or how we can reliably enforce this condition in a test-case. >> >> To give some more detail, a minimal way to show the register as unavailable is: >> ... >> $ gcc hello.c >> $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' >> Temporary breakpoint 1 at 0x512 >> >> Temporary breakpoint 1, 0xaaaaa512 in main () >> $1 = >> ... >> >> I'm not sure why it's unavailable. >> >> It seems the register was added as part of some tls support for fbsd arm tdep. It could >> be that support for the register is missing in linux arm tdep. >> >> It also could be a kernel problem (used kernel is 4.4.190). > > I did a bit of digging today and the $tpidruro register isn't available > via ptrace in the 32-bit Linux kernel, but it is available for an > aarch32 program running under an arm64 Linux kernel via the ptrace > compat interface. > > Support for this isn't implemented in GDB however, so at least for now > IMHO it makes sense to disable the org.gnu.gdb.arm.tls feature in > arm-linux and arm-netbsd (which from a quick look at arm-netbsd-nat.c > also doesn't seem to support accessing $tpidruro either). > > I'm testing a patch that does this and I'll post it if there are no > regressions. Thanks, I think that would make sense. The only time we should be seeing some "unavailable" registers or memory is in the context of tracepoints, for things that are not collected. Seeing an unavailable register here is a sign that something is not right. Simon