From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by sourceware.org (Postfix) with ESMTPS id 7157C385840B for ; Mon, 29 Nov 2021 15:37:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7157C385840B 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-wr1-f46.google.com with SMTP id u1so37669623wru.13 for ; Mon, 29 Nov 2021 07:37:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=SWwqhWbRcMH+ny8PECeo0H4Is6e244azim8A5DvzzNw=; b=dxSkLAcqe/CKPJVu7iaf6Ehr7XFQCnGbsU3S4pEksVVuw5p+LYO5mulsFLNH5Ey1sC 5HBK8+J9+mXJtPq/mLpM68d0UGgR7EThLJ2AUrcVBbpVmunCyd26+FjOjsn+/8cWaFG6 kMr/rzjUpOV6DWSURdwyQXG6vldZ0zeG3rjpoA3bZEkN8MXT8SsC/7OLht5A8N8na7ks UHkOW/faMk4+yGC3g+a24HiF9YJs8YqlIwxtvcubFwnbSxek1lx15kg34ZmJzdpZAG+/ 6Rrof6LhsulkOeOTLAXbH5fBSh6v/5n/uw14iRqlKlpaB3W4G8YF7Tf5na+eHJ+HB/fM rNhQ== X-Gm-Message-State: AOAM533VvhKbVdhZjsgt5dfLThXxMC8HVnjpZ6xFoo8JU6dFr9+bBTWS AXG4sZW85j86XW3Fj0vmAVE= X-Google-Smtp-Source: ABdhPJxSOfsoKXUL96+9hO8tyEJ24oXo/cuxhN6sCDfEXcCaU2LZk1WwKeo3tvqEeX1Fi7hZYGcLfQ== X-Received: by 2002:a5d:4f02:: with SMTP id c2mr35595567wru.496.1638200223053; Mon, 29 Nov 2021 07:37:03 -0800 (PST) Received: from ?IPV6:2001:8a0:f912:1a00:fb57:3faf:e98:b979? ([2001:8a0:f912:1a00:fb57:3faf:e98:b979]) by smtp.gmail.com with ESMTPSA id y15sm17456989wry.72.2021.11.29.07.37.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Nov 2021 07:37:01 -0800 (PST) Message-ID: <342f0bb2-5b42-24e3-b2bf-a6d5e3a00e33@palves.net> Date: Mon, 29 Nov 2021 15:37:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH 1/3] gdbserver: hide fork child threads from GDB Content-Language: en-US To: Simon Marchi , Simon Marchi , gdb-patches@sourceware.org References: <20211029203332.69894-1-simon.marchi@polymtl.ca> <20211124200444.614978-1-simon.marchi@efficios.com> <20211124200444.614978-2-simon.marchi@efficios.com> <1e343901-2199-1034-2c05-be8668e2c8a5@palves.net> <682fd2be-73e6-3372-5b03-a9e94a04f101@polymtl.ca> From: Pedro Alves In-Reply-To: <682fd2be-73e6-3372-5b03-a9e94a04f101@polymtl.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 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 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 29 Nov 2021 15:37:07 -0000 On 2021-11-29 12:46, Simon Marchi wrote: > On 2021-11-26 17:51, Pedro Alves wrote: >> Wonder whether we should instead have some: >> >> thread_info *target_pending_child (thread_info *parent); >> thread_info *target_pending_child_parent (thread_info *child); >> target_waitkind target_pending_child_kind (thread_info *parent); >> >> target methods instead of moving the fields. I haven't thought this >> fully through, though. > > At first I wasn't sure, I was thinking that having the fields directly > in thread_info would help avoid duplication, in case another OS (e.g. > NetBSD) decided to implement the same thing. But not really: even if > the fields are in thread_info, the bulk of the work (updating these > fields) is done by the target. Since the state is managed by the > target, target methods make sense. > > I will add a "target_thread_pending_parent" in this patch, a > "target_thread_pending_child" in patch 3, and in your series you can add > a way to get the kind. Either a new method, or I was thinking of an > output parameter on target_thread_pending_child. Sounds good? Yes, output parameter sound great.