From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic301-21.consmr.mail.ir2.yahoo.com (sonic301-21.consmr.mail.ir2.yahoo.com [77.238.176.98]) by sourceware.org (Postfix) with ESMTPS id E2A633858D38 for ; Fri, 12 Apr 2024 10:44:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2A633858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E2A633858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=77.238.176.98 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712918657; cv=none; b=LbZyOhu+3u4lgsd0EidwfSMEIO6uLd75yj7nNFiWzv8KkZGCx+0naGJz1ANXLBiU37bfHaX0BfRjhplZerNMgZeeK5dOs6jol6kExWwhClPyagtmevj2WhoAoJZ1ugqydunzb2zbxcStRBI2iPTC2gG9yqJkhDTnuvj7K5th/zc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712918657; c=relaxed/simple; bh=C3YUzeYmKyZqzH5W40DkvLZ7cHdAMHGoyXAvbLRV9A4=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=DNd1sUycwhwWYQqgim0LJ79E0oXjUyaF537yTWT2k3mrYCysNJMTsYqQh9cJi4ktZ2g498oQkv2FJMcflK2bbsOLsiDRdxrvoyiQcrVjRbkaekyrifAUdjuMNNmdTW7Vx6c9JWe+I25ab14V1JsAEUDc/1jysd68CTplBTGx/7E= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1712918653; bh=C3YUzeYmKyZqzH5W40DkvLZ7cHdAMHGoyXAvbLRV9A4=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=RfnBFWyaJcQu3vCXTUisKL9iZe89hPdSoY1gZc9a4YwYvfmnb2HBujdjLPXqyWGyWDkkxMBr5qbY7l07ukCGvHavltO7/UgQS7WQ35yjjvXq9QVP/R3ATujPefMLCzCHm2fvrdASVqpIMTgPkqpDw8gxNAi7FweK5BeXXJHO+suBRAnrmnZqbnFUCWc5dUjsD8DlyvL+wRKn4DVD04H9+o+Imcl5c+LNH5i8UaRUAHgXuwe7rqJD1OWuFW2X80pJzjXdVTqXSpP0BVGsO/GTgpsML6wQqsVgDaxjR0PQ00TwTaubNBH2JNhfNok/VMtyJdPJSVEBDJ9qcSMnu5c25A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1712918653; bh=kCZlAXbC+YaD09gon2+qln4hnw07VWuZhg3SIAU2B9d=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=LqC8wA84T6vnJGhiP3edFKNMFRDiNaSvUi4XnnLOlueO19GkLFQiygDsZxLU97v37L2tdqqL8gpxjFJ/VU6pke2fMTbI8YOKHQNZR83efNQw4AWNjm0R+oFzPJsckaw6bk1iEO/eOTJ1uCdwY91o97J03plEb/vImNUAnTw6zZi0a0O0rXbAfUfY/6P3iD37xbdFM7L2annvJ+XvtG5xFRGNhuyRyMzGr971oFXLumpJVZHWTY+zKQj2tKbf8ZMHFgzI5B+7yOCQfiunVRMchWN87nT8/vtdB1XmptTleo2ql10fSWS6SWOCkIQDeQ5CqakGH9oN1g/OEpzqruzjmg== X-YMail-OSG: TTq2jfQVM1nRvQBPmZfqwF8_8bPPjH18AmNArUZtri.7ZjfzI3O4hfhWPb4ty2D xBexGbieWi.leBwINTRDMiDknfMonxS5ZW2zqc4ibea5uUZy6NH7CpS0RV6zOoT1kPCJ1FxwwpuP XomqCUlWaQDzDqu8ZEq_H4Fki5fazVrRrtzXaJh1Vf10Q3BPmbxifCbDTve2HW0E5g3zn4TvRCOR pMdJQsodksYPe7ThBRM242bjizDUAWsitFQxoAI.uZ0_px6pWz6j9fjYgZQxFx2CU2CdrJBhApEF sEBVXkOHPPqsNL7w7auod44Km6bR4d1xLgIIT0ejnghw0nPHjmX08m._bGDE5s3mlePatUZzS_F. 5VfZG56ridgH2x.iTYXIjiNmgYtBMlVzOWhV3n2y8f9IhBREHzdoAv8dI6ELrUWbd6KzObkuy4ZY tzJHEeZLhEH1bf._2FmtqpIkwCCkD45N6q3Me4DE__aB9D7M21KasKyaxTAd9v8xevEn1q8G5pXd jDnC_ZVKehp6ggdhC2ZOzZj3dWRQjYkm6.2VC3eSdNy19HAQD1ftz419zzYA1imm8_zyqp47zlJv ywUphS8W6pnJiuhUoM_Pxmv73P2AWzrsX0ArOiebo1VLb0T3mEP_5JSEZBZZ26Mw0r1ZDp0HRKJ0 UqCYagiBB5knBijDVxHMnMDBGRIEyPmbj.vXnNMZfHktwnbCdUQi57SZoAs.9Dp3MJXYlWtSI.KD YXRrLJrCBdkml.VDr_p4OBXwb_Niv34Y5e9D3nBWd5fvZaxrEZtdx92I.zemurXx83o51Gpjn1d3 e2cd1nlQtH9xPRcTyf8JEdf3B35yXec6GsLSOAs7xxkV7qzObWUhwqWMsT6wgbuu5apG4r7njewV MbJguA4AZI7cfgHnkrhMNBH4v2EK4_nAYkIj6CCCYYkYiXX.jDUiYYfK4A6Bq2okhB.HM7Ql6T79 OJz7xTBIyDfII_hoZdmoYnjzQ5w20M8S44aH1DmlbDGxJG2WWFcRdhJ.be3KU4Eu_dkXyRcsmkxd OkCNCwADcL.WllQ1OmX_PouZA_iALsIE3RCeI5kRxLXEccKs6PExOdYWXLCVocwiZShCcpUwcZqx zd.MLvNnwzp65_m9Ye_JkXotSvwKxUj9sytEJbR0tzupp.djvGS1c3xOlLmLWn4Rx42xPBQ0_JRL 0cAEO3eFAaNnMAPOW8aHteh9HORlA34BUoKZohblHe52z2d_AJOPzfpraVDF_3Kz_.5YAC0OYaMZ ox9fHMXvLEg9AyE_.sp7Ordk3n78wGfHwCVHY1knE5DxwbpLWO8cD8wOUCvhwgQ4yRwvPDTb32ZW ZhFMmEWgcH.BjzJDzFgzy3S7MG1wFpWagJ2opElnjat9UspppHPsCAQYIN7GKxAJKtNvF.pz2YgT 0YGBeOQfHNoG7xTIVGMZsBX.MrSchq.byQhbrG4K9LFJQkUuyPwoO4CgNXcDJnX6WUWEAWSXfwge 9yGfi05xjw2NetlpL1WQI66v4ZoY0fco9nw09tcY7irAIf77QUAnQhOWkk9pCJfN9kZw4ZDezTrs Gpi1WKvWlnq8mxrtoUoIWCpeKLhg1OZTh0f7cndRb.xb7X6PL4hZM00QSbTEH402VEJ.WKvj7P2o arj0mwrUJwVZygo0utRn1MUcEPqVQy7zoHm4rZzquiMw9NgVrQvhGIsQzEwdrSwiJQptNw.KGau. FtA5whrecmZhkSvG0cnINQgc.BsTCkrpYZiGo3y4NnZABhvZdteyIy0.t6_jSnYbbFL_9mzsNh4m LhfN8YVadUsZzf7MML7ZXoRuw6Bz7jyf2GAEGVvUGtOdoJIDVMe9MH.UdPyUbgk9veRmyjYSoPZq ym8G0epgpYyjhLx3ql5HtNfoHU7dhs7rplQoj_MbteOH63zzGCbRqwjIqRz3_KwZ7WDH2159gOyD teOy1sen0ukssI7DWF0PQlYdJdIlpj2WlsaV00MJm7MS_7gVL8oKtlcrc4QxXEwH2DpkDiNeADBK DIvfXbddta.1jiu622XeSku3Pw43QkObbPcgeUzb4Dl1f.ac7eMvyiIV6ldi3hKx7hUioxITekQn x9uer7f4k9wUOW0hk4ju4qNtofvPutwV3_RP.BLoRYtBirjpwsTJYYXPLX6JHzFRZlBW0lXj4e_G mMAHQQfffkzmCzX7Xn_2gzHSNFXsgn0SMY1LupaThVyNQZmxf2BZouSlfM4U2LKEr4Q8xLKY9KJp DZZGTmpiORAgU8IyGSrfw1SGFxdz0jg1qzxOERYxl X-Sonic-MF: X-Sonic-ID: 79d030b7-393f-4e52-898c-fb0c901a5d97 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Fri, 12 Apr 2024 10:44:13 +0000 Date: Fri, 12 Apr 2024 10:44:12 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , Pedro Alves Message-ID: <1018634550.12675968.1712918652616@mail.yahoo.com> In-Reply-To: <20240411113941.204268-1-pedro@palves.net> References: <20240411113941.204268-1-pedro@palves.net> Subject: Re: [PATCH] gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.22205 YMailNorrin X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: Am Donnerstag, 11. April 2024 um 13:40:25 MESZ hat Pedro Alves Folgendes geschrieben: > Old RHEL systems have a kernel that does not support writing memory > via /proc/pid/mem.=C2=A0 On such systems, we fallback to accessing memory > via ptrace.=C2=A0 That has a few downsides described in the "Accessing > inferior memory" section at the top of linux-nat.c. > > The target_xfer interface for memory access uses inferior_ptid as > sideband argument to indicate which process to access.=C2=A0 Memory acces= s > is process-wide, it is not thread-specific, so inferior_ptid is > sometimes pointed at a process-wide ptid_t for the memory access > (i.e., a ptid that looks like {pid, 0, 0}).=C2=A0 That is the case for an= y > code that uses scoped_restore_current_inferior_for_memory, for > example. > > That is what causes the issue described in PR 31579, where thread_db > calls into the debugger to read memory, which reaches our > ps_xfer_memory function, which does: > >=C2=A0=C2=A0 static ps_err_e >=C2=A0=C2=A0 ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr= , >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gdb_byte *buf= , size_t len, int write) >=C2=A0=C2=A0 { >=C2=A0=C2=A0=C2=A0=C2=A0 scoped_restore_current_inferior_for_memory save_i= nferior (ph->thread->inf); > >=C2=A0=C2=A0=C2=A0=C2=A0 ... >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D target_read_memory (core_addr= , buf, len); >=C2=A0=C2=A0=C2=A0=C2=A0 ... >=C2=A0=C2=A0 } > > If linux_nat_target::xfer_partial falls back to inf_ptrace_target with > a pid-ptid, then the ptrace code will do the ptrace call targeting > pid, the leader LWP.=C2=A0 That may fail with ESRCH if the leader is > currently running, or zombie.=C2=A0 That is the case in the scenario in > question, because thread_db is consulted for an event of a non-leader > thread, before we've stopped the whole process. > > Fix this by having the ptrace fallback code try to find a stopped LWP > to use with ptrace. > > I chose to handle this in the linux-nat target instead of in common > code because (global) memory is a process-wide property, and this > avoids having to teach all the code paths that use > scoped_restore_current_inferior_for_memory to find some stopped thread > to access memory through, which is a ptrace quirk.=C2=A0 That is > effectively what we used to do before we started relying on writable > /proc/pid/mem.=C2=A0 I'd rather not go back there. > > To trigger this on modern kernels you have to hack linux-nat.c to > force the ptrace fallback code, like so: > > --- a/gdb/linux-nat.c > +++ b/gdb/linux-nat.c > @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object = object, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 poke would incorrectly write memory t= o the post-exec address >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 space, while the core was trying to w= rite to the pre-exec >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address space.=C2=A0 */ > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (proc_mem_file_is_writable ()) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (0 && proc_mem_file_is_writable ()) > > With that hack, I was able to confirm that the fix fixes hundreds of > testsuite failures.=C2=A0 Compared to a test run with pristine master, th= e > hack above + this commit's fix shows that some non-stop-related tests > fail, but that is expected, because those are tests that need to write > memory while the program is running.=C2=A0 (I made no effort to temporari= ly > pause an lwp if no ptrace-stopped lwp is found.) I can confirm that this fixes the problem for me, thanks. Tested-By: Hannes Domani