From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by sourceware.org (Postfix) with ESMTPS id 959B938582B0 for ; Tue, 18 Jul 2023 13:09:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 959B938582B0 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-f48.google.com with SMTP id 5b1f17b1804b1-3fbc244d384so52484055e9.0 for ; Tue, 18 Jul 2023 06:09:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689685751; x=1692277751; 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=BJaaZP4aXkxxOa6SF/hp8iZWJkjvjluyB5/Hjxdt4pw=; b=ByMd8BxpNTCC1OficL7eZ4gNXVcymAdKiGjqqeLj55ojwAcDxxyhzQ3GUVBs104N62 mHJ3bkwzTddJVed+abHvj/9jPw70PaoWAMk1UGYvtjjGlTSWtcfgl9x+ffZPBkTy2egN 568kzalUdbaRtWLh17LkuU+Tz8ZD09YzXaSODlZVpPzGxjV/a/spr5Ysli8lF+z8wTY9 1Mu/UwegsfgeJVTlPE4Rt/ipA4VS9nXXLa0UlxibnKDKE2TJnLsxHFwfvtFXmpzdpoaD mn+Oum0ymtGjeXREeXTmpUAWkoWzZFNL/mtXkSLWb8IOTrJViz1L7zL+7PQ41VEVZb/P tfbQ== X-Gm-Message-State: ABy/qLYcoSNlm4RXpPSOVyuCth9BSkcdwFsUG6m6muT/N5paki16UixC nodpNzp9a/ezJPCsu9k6osQ= X-Google-Smtp-Source: APBJJlEtixK+g4SNQCAD7XgZfr7Dwxv/5CapV7T0Y0UxjqmLUJV498CQ5H0xhxc1JPz48k2trc5QXw== X-Received: by 2002:adf:ec42:0:b0:314:11d7:c919 with SMTP id w2-20020adfec42000000b0031411d7c919mr12114908wrn.49.1689685751028; Tue, 18 Jul 2023 06:09:11 -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 v16-20020adfedd0000000b003063db8f45bsm2379583wro.23.2023.07.18.06.09.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 06:09:10 -0700 (PDT) Message-ID: <90f33e9c-a586-a94a-3584-5288ce14d410@palves.net> Date: Tue, 18 Jul 2023 14:09:07 +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: Tankut Baris Aktemur , gdb-patches@sourceware.org References: <20230620083519.1295801-1-tankut.baris.aktemur@intel.com> From: Pedro Alves In-Reply-To: <20230620083519.1295801-1-tankut.baris.aktemur@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 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-06-20 09:35, Tankut Baris Aktemur via Gdb-patches wrote: > Since commit > > commit 7f8acedeebe295fc8cc1d11ed971cbfc1942618c > Author: Pedro Alves > Date: Tue Apr 5 13:57:11 2022 +0100 > > gdbserver: track current process as well as current thread > > gdbserver switches to a process, rather than a thread, before > processing a memory access request coming from the GDB side. This > switch sets current_thread to null. Some memory accesses on certain > targets, however, may require having a thread context. Therefore, try > switching to the selected thread first. If this fails for a reason > (e.g. the thread has exited), switch to the process. The reason I liked always selecting a process (with thread == null), is that it made the corner case be the case that runs all the time. I.e., any target backend that incorrectly assumes there's always a thread selected, is immediately exposed to the problem scenario and is forced to fix it. Trying to select the thread first loses that. If the access is for a thread-specific address space, and the thread exited, what is supposed to happen? Is the backend supposed to error out in that scenario? Or will it misbehave? How do you tell what address space the access is targeting? Are you encoding that in the address, or do you have more changes to gdbserver, and maybe RSP extensions? 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;