From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GrSeNQDH4mMNkywAWB0awg (envelope-from ) for ; Tue, 07 Feb 2023 16:47:44 -0500 Received: by simark.ca (Postfix, from userid 112) id CD70F1E15D; Tue, 7 Feb 2023 16:47:44 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=lXZL3/9k; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 391FF1E112 for ; Tue, 7 Feb 2023 16:47:44 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E8AE83858414 for ; Tue, 7 Feb 2023 21:47:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8AE83858414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675806462; bh=Xx6K19HHmnq7pNRdbzLYGBp0K09ZvaaoqRVjDimaeQo=; h=References:To:Cc:Subject:In-reply-to:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=lXZL3/9k4Gop02qG2elCvFaMv9pUF5eNI6q4+eelP1n6ywA9r6D1Ys1BbH2K1+kJ1 Sv2+2FgvlURPUFzrmK8FSzRtHu4qgQvB0X8Om3s8GOOH5fNLDDwFbAV9DbG7R9AIc8 rkRQz9yLAobKKG0DwZRmqTG3nHTswepxK/7D3SP0= Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id BF9BA3858D33 for ; Tue, 7 Feb 2023 21:47:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF9BA3858D33 Received: by mail-oi1-x235.google.com with SMTP id bd6so4892984oib.6 for ; Tue, 07 Feb 2023 13:47:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Xx6K19HHmnq7pNRdbzLYGBp0K09ZvaaoqRVjDimaeQo=; b=p+1XOq3zgifZ85ZukwexANMdekzLqoKIrYlhyPjHLCbPSRi62ql1AvuTqmSOY0J/On z6D94ZN1y8UZNZ0YYLYBtRp8LdMIxWnDpyGJ4tTSBWe1BG6Nh9TRZ18d9+0eDKZZuq2M lsVCNTrXquSH+HExo7gXFL2ero6BwHenqOxxLuH7OE1Ak/2w1ZNtADk7ml6AIEDc9oae Zvd18DZrsm/XgPuDZdU5go4Lwp8tKpEe8bG2r3GIQq4MM2XMs0IB4bG0wZW8YWqXhWK7 8ooDZv9TTQjXOrDTJYhGhMtoyVswKcAN/mcvJ9jHryYpLKhVY4zeNjpAX4hp0oEHM9FU h9Vw== X-Gm-Message-State: AO0yUKWQypLq/bghcJLPtCttgrO2hY5h1biiuqCr6nTAZkm/w3XoZL2s tmla7vMX+5dRh214bIl1Og4fPg== X-Google-Smtp-Source: AK7set+9+6lPB7YtYl3aPlBUdzDgtwrrfduO8duYsgBHTJ9+KHQPTsLqZsqDdViPCMmU3NRp1M9L6g== X-Received: by 2002:aca:1003:0:b0:37b:568:5b88 with SMTP id 3-20020aca1003000000b0037b05685b88mr2334890oiq.24.1675806442075; Tue, 07 Feb 2023 13:47:22 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:56ca:1532:909:af92]) by smtp.gmail.com with ESMTPSA id bk30-20020a0568081a1e00b0037880fdb1f6sm6152567oib.24.2023.02.07.13.47.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Feb 2023 13:47:21 -0800 (PST) References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-3-thiago.bauermann@linaro.org> <9072a00d-adcb-b317-3957-2d84e3c149ea@efficios.com> User-agent: mu4e 1.8.13; emacs 28.2 To: Pedro Alves Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH v3 2/8] gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap In-reply-to: Date: Tue, 07 Feb 2023 21:47:18 +0000 Message-ID: <87r0v19mhl.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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: , From: Thiago Jung Bauermann via Gdb-patches Reply-To: Thiago Jung Bauermann Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Pedro Alves writes: > On 2023-02-06 8:16 p.m., Simon Marchi wrote: >> On 2/6/23 14:54, Pedro Alves wrote: >>> AFAICT by playing with debugging the gdb.threads/leader-exit.exp program, >>> you can't read /proc/PID/auxv if the leader thread has exited (is zombie). >>> >>> Maybe that ends up not mattering in practice, not sure, but it is a >>> behavior change. >> >> Even if we can't read /proc/PID/auxv if the leader thread has exited, >> auxv is still a process-specific resource, not a thread-specific one, >> right? > > Right. > >> So, I suppose that the target interface could still accept a >> pid, but linux_process_target could pick an arbitrary non-exited thread >> from that pid to read auxv from? > > Right, I think we can do that. > >> Although I don't know what would >> happen if that chose thread has just exited and we haven't consumed the >> event yet. > > Not sure either. And I don't know what happens if the thread hasn't > exited when when we open /proc/TID/auxv and then the thread exits > before we read from the file. These cases should be confirmed. We may > need to keep looking for a thread until we manage to open & read the > file or run out of threads. Ok, I will look into that. A simpler approach though would be to fetch auxv at process starts and cache it for the duration of the debugging session (since auxv doesn't change at runtime, AFAIK). Would that be a good solution? > BTW, I just noticed this "current_thread == NULL" check here: > > /* Handle qXfer:auxv:read. */ > > static int > handle_qxfer_auxv (const char *annex, > gdb_byte *readbuf, const gdb_byte *writebuf, > ULONGEST offset, LONGEST len) > { > if (!the_target->supports_read_auxv () || writebuf != NULL) > return -2; > > if (annex[0] != '\0' || current_thread == NULL) > return -1; > > > Since we're removing the thread dependency, I think that check should > be replaced by current_process() == NULL instead. Ok, I'll submit a patch with this change. -- Thiago