From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by sourceware.org (Postfix) with ESMTPS id ACFE03858D33 for ; Tue, 7 Feb 2023 15:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACFE03858D33 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-f42.google.com with SMTP id k8-20020a05600c1c8800b003dc57ea0dfeso13446983wms.0 for ; Tue, 07 Feb 2023 07:19:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lLJ3hATOjhis3i4BlVeYGXNiTK7rqhFtWFUeI/W9eS0=; b=favxWUqoaYH3lCI5kxHs2s4RVYPNgYEPUA4gCc/BWPuDe41KmsasKLi6+YTjCRMCFC smFFXCbYfBwafVKdq1lAQJs0jmSp7Nre+f6AEOHKffLE4OEuPPkbAJ/NCG7n1ng374uL WxYi65YyTHxkOvV1FWwXW3nx4ePzfvOCL3Q5XMgauokRYR44XgooMDxHX14ImtEn6ShD rYuIzjGpO2XzAc7YQSwXmX8jG0DLuoOfqP9SpKcOSeVNnVr6f43UmNuYpXhPoVOjHrOM j+srRX0WHMwC6NI7qCnorRJTdmsPcff1OQ5MC15Qy1H1+Hj7sbF/NCV3cVINh3v78Doz KxOQ== X-Gm-Message-State: AO0yUKXiK0SKKO5rjGk7K2njgNHIAkrs9NpvG8bau+ZQ3K/PtFooSOKI 5SWf6wnXcmIspNsvtvyFtpogZ/ewCFoOjQ== X-Google-Smtp-Source: AK7set+3k7TV800/t75jLhsnjYeoQNW7H7G9+hfem7AdAL7psGtFPVVrtbjyD5BlcuuXq8+VXhFMrA== X-Received: by 2002:a05:600c:9a2:b0:3dc:576c:ab07 with SMTP id w34-20020a05600c09a200b003dc576cab07mr3533732wmp.14.1675783191235; Tue, 07 Feb 2023 07:19:51 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id 14-20020a05600c228e00b003dd9232f036sm15855263wmf.23.2023.02.07.07.19.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Feb 2023 07:19:50 -0800 (PST) Subject: Re: [PATCH v3 2/8] gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap To: Simon Marchi , Thiago Jung Bauermann , gdb-patches@sourceware.org References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-3-thiago.bauermann@linaro.org> <9072a00d-adcb-b317-3957-2d84e3c149ea@efficios.com> From: Pedro Alves Message-ID: Date: Tue, 7 Feb 2023 15:19:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <9072a00d-adcb-b317-3957-2d84e3c149ea@efficios.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. 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.