From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 0F3BD3858D20 for ; Fri, 31 Mar 2023 03:44:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F3BD3858D20 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-x22d.google.com with SMTP id y184so15806788oiy.8 for ; Thu, 30 Mar 2023 20:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680234294; x=1682826294; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=OBRHyHtsU/BisRUnuZRfVBJBtUaxQ61bHEiKQ4p51Rk=; b=bZH4N8R8koFCgz5wa6WWTgzsxswhvGaEvAkorOb6ewBJeeF1sqk62CLzHf1qIy2ahA 8bdnrbqiTqP1BGVD3QB5/IMD/ZproWCd8SCDQhpAiq994/mHFtg3Q18wVQEjKrCJAAoM Lp8Yut1dKLfC4OrmRpGF0z/f/Qfe3KDjGeWzOny7yJ8mH5CkALRSPNkRmpJYJyyVUjQd wcMIEm9g28ZD6ifYRVERosFbN80X/fmCxbNiDovx4hS45fjpVcW4vb1PGU85cJxlgj9w c8nIbplHMTP95mDQdNHt3iDdo5mjjPa980OHKcBEn2DRxP0GhEmsWkBsjSr3MiCmTpKA 85sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680234294; x=1682826294; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OBRHyHtsU/BisRUnuZRfVBJBtUaxQ61bHEiKQ4p51Rk=; b=fffdJXAqZECnAKt9KpDAQR92jRYT3vxaON2vO01ymueSJ2mT+YL2Qiw2ryf2LSucC+ WFh3Z1Qq7R/HgriUjVlU4LmE1QGwHlSvvlwj/+ctNbnTHvYPSac5TRCBhE2GFwFcOx5U /j/dTpKpqMYSKLxGfu3gsl9TbEz7Yjrze0Ss4p5R2GRQ76xfRhlulh65HEb4afj2lgnV fQo+DHNZKOh96GpmN3Qc9yueeeDBJ8wnJVBSu3Wv54/jRM6Q5z3dzSREkmoV6AiKau5U 3Vkdnp6zIQstYw3RyBqoh4GpNkMuScYR/SgLygjDGk8i0NeJqCYpv2GGj6Kebkr1SDMV Xuww== X-Gm-Message-State: AAQBX9eI/M9/4X9CNZsukvEZOiVa95DV1YGwizG3NatiM7hK3JUgdY9Q yveEy1keiBkUy+Ii6FFmzpxW18IGLa44uUsNzqY= X-Google-Smtp-Source: AKy350a8UX5qKjtDGdplWyf5w4YDS1mTSb9uH6TTRxrVGfgytBggRuKH3g1aZHOSC5zv8VbELth+YA== X-Received: by 2002:a05:6808:608f:b0:389:5104:84db with SMTP id de15-20020a056808608f00b00389510484dbmr5609992oib.35.1680234294310; Thu, 30 Mar 2023 20:44:54 -0700 (PDT) Received: from localhost ([177.124.15.55]) by smtp.gmail.com with ESMTPSA id a1-20020a05680804c100b00384fa407a06sm589680oie.8.2023.03.30.20.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 20:44:53 -0700 (PDT) From: Thiago Jung Bauermann To: gdb-patches@sourceware.org Cc: Thiago Jung Bauermann Subject: [PATCH 0/5] gdbserver: Follow-up on linux_get_auxv using PID parameter Date: Fri, 31 Mar 2023 03:44:27 +0000 Message-Id: <20230331034432.3037148-1-thiago.bauermann@linaro.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 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: Hello, Back in February, I pushed commit 43e5fbd8b788 ("gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap"), and mentioned that there was no change in gdbserver behaviour. Pedro corrected me, mentioning that before the patch gdbserver would read the auxv from /proc//auxv, while after the patch it would read it from /proc//auxv. This causes trouble in case the inferior's main thread exits. I created a testcase exercising this scenario (the last patch in this series) and confirmed that both GDB and gdbserver have this problem (GDB wasn't changed by my patch). The problem is largely mitigated by GDB's auxv cache though, and is very hard to hit because one of the first things that GDB does when starting/attaching to an inferior is read the auxv and cache it. It will only be a problem if the cache is invalidated by one of the cache-clearing events ("inferior_exit", "inferior_appeared", "executable_changed"). In the discussion about my patch there were also some questions about other race conditions in this area. I created a test program to experiment and these are the results: Q1: What happens exactly if GDB/gdbserver tries to read /proc//auxv after the main thread exits? A1: If GDB/gdbserver is root, then open() will succeed but read() will return 0, indicating an empty file. If GDB/gdbserver isn't root, then open() will fail with errno = EACCES ("Permission denied") even if it's running as the same user as the inferior. Q2: What happens if an inferior thread exits after GDB/gdbserver opens its /proc//auxv file but before it has a chance to read it? A2: The read() call will return 0, indicating an empty file. Patch 3 fixes the problem for gdbserver, and patch 4 fixes it for GDB. Patches 1 and 2 implement a couple of suggestions made by Pedro in the same thread. Regression tested on native and remote aarch64-linux and x86_64-linux. Thiago Jung Bauermann (5): gdbserver: Use current_process in handle_qxfer_auxv gdbserver: Use the PID of the current process instead of the current thread gdbserver/linux: Read auxv from any thread of the process gdb/linux-nat: Read auxv from any thread of the process gdb/testsuite: Add test that reads auxv in a multi-threaded inferior gdb/auxv.c | 16 +++++++ gdb/linux-nat.c | 40 +++++++++++++++++- gdb/nat/linux-procfs.c | 67 ++++++++++++++++++++++++++++++ gdb/nat/linux-procfs.h | 7 ++++ gdb/testsuite/gdb.base/auxv.exp | 56 ------------------------- gdb/testsuite/gdb.threads/auxv.c | 62 +++++++++++++++++++++++++++ gdb/testsuite/gdb.threads/auxv.exp | 30 +++++++++++++ gdb/testsuite/lib/gdb.exp | 62 +++++++++++++++++++++++++++ gdbserver/linux-aarch64-low.cc | 10 ++--- gdbserver/linux-arm-low.cc | 6 +-- gdbserver/linux-low.cc | 21 ++-------- gdbserver/linux-ppc-low.cc | 6 +-- gdbserver/mem-break.cc | 2 +- gdbserver/regcache.cc | 2 +- gdbserver/server.cc | 7 ++-- gdbserver/tracepoint.cc | 2 +- gdbserver/win32-i386-low.cc | 4 +- 17 files changed, 305 insertions(+), 95 deletions(-) create mode 100644 gdb/testsuite/gdb.threads/auxv.c create mode 100644 gdb/testsuite/gdb.threads/auxv.exp base-commit: 66f76c545b293f8b89fef0f996a3a48fa59fae61