From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x235.google.com with SMTP id bd6so4892984oib.6 for ; Tue, 07 Feb 2023 13:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=Xx6K19HHmnq7pNRdbzLYGBp0K09ZvaaoqRVjDimaeQo=; b=TGCvGZ6rn/SWaPnpmVBaNjKg89zDGephrz2smK6Y5PUFkn6LaQob3LTwfI0dg+Rzvx 52UeutRWSryL7DvW83/6v4sXy4U8QMDFU2aC7s1zy6veHtiqDBiPqTrTdTg9jT5SIW21 sJEwSAc7meyYb//lUjXfc4ny68U5zO0ISWipA94KpAm67z9RQmekuI/g6YU3BQPMnhnl xlr8pjgYsAp6hf0JYAksLUoApgJVNaT8W14tanl1g4HkG/I6pF2fogW1XkIcHtqrgOIN e70dAQ9zQwSY5ZZU6XkMtl0cw/p5EeUFN9Sb9nliInx1K0R5dJvrQf3mTQUu7jRbcLwW QrgQ== 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 From: Thiago Jung Bauermann 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-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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