From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id F220F3857351 for ; Tue, 18 Jul 2023 14:03:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F220F3857351 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-f47.google.com with SMTP id 5b1f17b1804b1-3fbc77e76abso52996285e9.1 for ; Tue, 18 Jul 2023 07:03:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689689011; x=1692281011; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fCAGzow9wNRS9vSI1AeRYD84QtYthxd1YZ7HiBkhnzg=; b=MZr6dqP5eZBXKKLd0yQOENPP+4+IqGOl9K8qBw5ix1nBavIBwxBIjLBM9g2EXLiGDQ Vi4gAolOX4zdvYlCOLhnKMMtstJ8tM/oah1M/u9//7DKLHPeGLAVhKQU+MLvg9GUjXmi iDXVQ/XYmHHOks68o/4jzpBSnK+sgnS5Tptu7liuiEczYO+HFi1L0xXCrEu1Ne42HTFI lrZluAM5OlTbPlZbtfIV2GE+iofKYUwoQdo2kyAQ+TaDQJeU3ROXjU2E2eihh790NmAT MyY4SQ/0cpZtJYfh67a6eXnvThQqovDUBHZ/8bq8Zi/JN8eWmGwNpok7oBJtjDROdWhn xIRQ== X-Gm-Message-State: ABy/qLYzenAdjhuz3RiG4g8r1Hqy3YPMa3qR6lHg/amgVn4UVtpgBHy6 kzNYV+PPnj9IiGnT7752eGC/EF8aKsI= X-Google-Smtp-Source: APBJJlF9mHXUX5b+BNZa22rtWoUDA7XblctTDaiYsZktfZPAl+ZuHr5QPEU8c6DmLdOGpcmLM53x9Q== X-Received: by 2002:a05:600c:2181:b0:3f7:f884:7be3 with SMTP id e1-20020a05600c218100b003f7f8847be3mr1996224wme.4.1689689011337; Tue, 18 Jul 2023 07:03:31 -0700 (PDT) Received: from ?IPV6:2001:8a0:f91d:bc00:2d72:1f79:bed1:65bb? ([2001:8a0:f91d:bc00:2d72:1f79:bed1:65bb]) by smtp.gmail.com with ESMTPSA id t17-20020a5d4611000000b003143c06135bsm2511015wrq.50.2023.07.18.07.03.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 07:03:30 -0700 (PDT) Message-ID: <24bc1dc1-b3fa-29e0-fc93-c202d9580a9f@palves.net> Date: Tue, 18 Jul 2023 15:03:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] gdbserver: try selecting a thread first to access memory Content-Language: en-US To: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" References: <20230620083519.1295801-1-tankut.baris.aktemur@intel.com> <90f33e9c-a586-a94a-3584-5288ce14d410@palves.net> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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=no 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 2023-07-18 14:36, Aktemur, Tankut Baris wrote: > On Tuesday, July 18, 2023 3:09 PM, Pedro Alves wrote: [ snip answers; thanks! ] >> I'm wondering whether we should have something like: >> >> if ((aspace_thread_specific (...) && set_desired_thread ()) >> || set_desired_process ()) >> res = read_inferior_memory (memaddr, myaddr, len); >> else >> res = 1; > > I believe `aspace_thread_specific` would have to be a target-specific > logic. Right. > What you referred to in the comment [1] above, i.e. "immediately > exposed to the problem scenario and is forced to fix it", would be caught > and the target would fix the problem by implementing `aspace_thread_specific` > appropriately. This makes sense to me. Exactly. > An alternative would be that > the target calls `set_desired_thread` itself, before accessing the memory, > if it detects that the request is thread-specific. I don't see any low-target > using `set_desired_thread` ever in the gdbserver codebase, though. So, it > might be considered a breakage of abstraction. Hence, your suggestion looks > favorable. Yeah, that'd be an abstraction violation. Ideally, the gdbserver backends would have no RSP awareness at all, and would even be reusable by GDB. Many years ago, the abstraction didn't exist as it does today, and the backends would even peek into the remote protocol message buffer. That was all separated out with the non-stop and multi-process work, IIRC, where gdbserver migrated to a target_ops interface similar to GDB's. Pedro Alves