From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EG+OE89xdGbBYgEAWB0awg (envelope-from ) for ; Thu, 20 Jun 2024 14:15:43 -0400 Received: by simark.ca (Postfix, from userid 112) id 438E91E0C1; Thu, 20 Jun 2024 14:15:43 -0400 (EDT) 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 330CB1E030 for ; Thu, 20 Jun 2024 14:15:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AC7CE389000C for ; Thu, 20 Jun 2024 18:15:40 +0000 (GMT) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by sourceware.org (Postfix) with ESMTPS id 06D7B3894C19 for ; Thu, 20 Jun 2024 18:15:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06D7B3894C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 06D7B3894C19 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.48 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718907318; cv=none; b=B4GuXbdkhoHlt+LVFW0quMmY8JJrTyYs/+Q3S/ZIAbmL44QGfVOCXwfQ3W/tbc7MYV6xfzORhWWwU75Cp38Mr4dksN8sgW1ZMdm7DFyIvAPSKlobxvx5zHYYgnFtn0KPRWea3U3M2KFZhJ+3lHiLzonNTyt8jB+Q1IHOdyel44g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718907318; c=relaxed/simple; bh=h/4oj92rOq/EhprSd1pFMoQ02an2BbA5bMAIjkGbYXs=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=QZc6OEtoWJAlfIKqGYiQ/SccFLC354lYVXZnsq7JFPrmhPrEabYVV+KYn2U0D+xwiJ3zKrTH7GWSWgnmPoBK7dA/c5eylArrEr8a1d163kGzKkjRjet5/Rt0zgz6qcaKBi3thL8hvz7UyyG6cXCOIoJO07k7p1y9mZt0JP4Ha4A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-363bbd51050so871327f8f.0 for ; Thu, 20 Jun 2024 11:15:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718907316; x=1719512116; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OcsSASLy2gxqXxzXeexmz4634W8pmsx4n789P99WApo=; b=uAtqV1CnV4y6f4LFOqeEgtuqf82yUUuG+Nw8FT7+TFe1QT0O1HKtOMPPTzQxao/JLl 53JFKtfbh8nLbW4NV+dIp9U60LG7LF0GEpA6485cJBWMj6FKnuezdP894/9MCFabko0z 8nfaGsE7IFzR9cieX/rL6aBX/KNIxl+S375Zj3i94K8oYumxoUXuwknvzhU9xTmGmVAe wCDMtvKxEMhPbJEEnsbdcgzJ2H+uursFr0bKRqAAn4Exz/dRpQhZ0YnBr4PeeE/k8IWB RVg+bTeIB14V2xcrfNNdJZMqH91Oy46VtatYie9MJnLdanlYh4HymXIhJLtP99wvh3gq iSUg== X-Forwarded-Encrypted: i=1; AJvYcCWrIi+lNW3d+TUnMrsQJyclJ3Wpu14ld3B3JckMMjX/fMcWM07gbIybJq6cV5H6C8uwG3BaNyYIeGtsRCyZaoRAVGK1BCt4CzTR+Q== X-Gm-Message-State: AOJu0Yyv9r/LhiisHJ1kurWKFTcGkAz76jpgAaSSMr6TUPVk9OFYZpWY gO4sfr5Gfsfb/VO5jrgbvef58m5Xqo/wepZU9hUuikK+knk6VW/VZ26ruw== X-Google-Smtp-Source: AGHT+IHLybp0tma6QC98Fdh+zLtjrD+38HMx+8OrpQGh4fKZB2I1op9kGLzBnRkCFdstoH7VNzg+MA== X-Received: by 2002:adf:f04e:0:b0:35f:10cf:6068 with SMTP id ffacd0b85a97d-363178984bdmr4669228f8f.27.1718907315590; Thu, 20 Jun 2024 11:15:15 -0700 (PDT) Received: from ?IPV6:2001:8a0:f91f:4900:8b21:a3d7:d496:930b? ([2001:8a0:f91f:4900:8b21:a3d7:d496:930b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-362e3e1abd5sm6358209f8f.47.2024.06.20.11.15.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jun 2024 11:15:15 -0700 (PDT) Message-ID: Date: Thu, 20 Jun 2024 19:15:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/tdep] Fix gdb.base/watchpoint-running on {arm, ppc64le}-linux To: Tom de Vries , gdb-patches@sourceware.org References: <20240607063525.9887-1-tdevries@suse.de> <9c0d2050-3555-47c9-bec8-1f2548eba9c6@palves.net> <88e14e37-9fbd-4dfb-ac37-6bee23eff372@suse.de> From: Pedro Alves Content-Language: en-US In-Reply-To: <88e14e37-9fbd-4dfb-ac37-6bee23eff372@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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.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 On 2024-06-17 19:22, Tom de Vries wrote: > On 6/14/24 18:49, Pedro Alves wrote: >> And, from another angle, why isn't aarch64 doing the same, why two mechanisms? > > Well, the patch adds a fallback, that aarch64 doesn't need, but that powerpc and arm do need.  > Aarch64 absolutely needs it, it's just that it already has the fix in place (by checking early in post_startup_inferior/post_attach). We're adding code to the other backends to handle it too, but using a somewhat different solution. If arm / ppc were being adjusted to use the same approach as aarch64 (like in a previous patch in bugzilla), then I wouldn't have asked that question. I see no good reason for multiple ways of doing the same thing. > There might be other targets that needs such a fallback, but that we don't know about. We have a testcase that will show us if so. > So, I don't mind your patch, it's certainly cleaner, but I don't mind a functional default implementation either.  > So, I'd move the target_can_use_hardware_watchpoint call to the default implementation of low_init_process. I'd rather not. Let low level handle low level things using low level details. > I ran into trouble building the patch due to type of pid parameter mismatches. > > After fixing that, I ran into trouble on ppc64le, because low_prepare_to_resume is called before low_init_process.  I guess it's while running through the shell, now that I think about it. > I fixed that by sinking this code in the function a bit: > ... >   if (m_dreg_interface.unavailable_p ()) >     return; > ... Makes sense. > > And after fixing this, I still ran into failures and identified at least two more locations that needed fixing due to the cleanup, at which point I decided that the cleanup part is out-of-scope for the patch fixing the PR. OK. > > So, this is what I have tested on x86_64-linux, aarch64-linux, arm-linux and ppc64le-linux. OK, let's go with this, then. Thank for testing! Pedro Alves