From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zexGLP9HsWovIy0AWB0awg (envelope-from ) for ; Mon, 21 Sep 2026 11:06:39 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=gcB74iUO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 95F581E051; Mon, 21 Sep 2026 11:06:39 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 546151E01F for ; Mon, 21 Sep 2026 11:06:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C9364BA79B1 for ; Mon, 21 Sep 2026 15:06:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C9364BA79B1 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=gcB74iUO Received: from YT5PR01CU002.outbound.protection.outlook.com (mail-canadacentralazlp170110005.outbound.protection.outlook.com [IPv6:2a01:111:f403:c103::5]) by sourceware.org (Postfix) with ESMTPS id 790584BA9020 for ; Mon, 21 Sep 2026 14:57:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 790584BA9020 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 790584BA9020 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c103::5 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1790002663; cv=pass; b=uwUIceS61UyJ6IPyGKkU9q+z+bxn1xpzJR1KTIkZix3nim1Qm0MzN/7R+rAU7KHwSoY9p6wAYZE5dVwGvcx89HeWKMWz/vr5KZ7joG/TN8fj3Sw8rwbtRKU+5Ap3f0fiPawUJHF1OT7sSSW8tsVJWXDzU9dzKgHNJ7rFQ5xk9MQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1790002663; c=relaxed/simple; bh=VleSRtLWnJSPw+29m5L00DtbycLvT6cVLc3T98/GfKE=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=HTn4AXIM5emqO7kPX4CBC9PB+eKL6ZWdaQI2A8uIN+bzwzUROg+wxly4VkJEG6E/QUh6EJMrhSxbe8KCCkukb9jT1v+y18lXPATl18G3zrkmotlRR6cqpr99Tr4Ez3D1W/FjqXj0mQuc+5x7OHmMLO3PW46nMjNaXMgI3L0A0WU= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=efficios.com header.i=@efficios.com header.a=rsa-sha256 header.s=selector1 header.b=gcB74iUO DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 790584BA9020 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BvCW/6wyoD4vebVySLS8VpUDglOtjEdmFcHvloZKlh1yGNTctZLNRoVVJ9pyefmGRucA2i2Qr4fiYyeQTUKOS1MgJo7BJIGXCqzZMbga07OyPJuwyuxiu5MjiITvX1N0lUOtK88Eo9ePn4MQycnpVn82VTWxzs6m2K0QQWqOlRx8eJ8ag3DFLfqPa/sFHmJ5p7dzVpv0rdf886VQhPlwiofFqkaI4y8l78BvxdciQFU9jhBRBsmavb5vv+I4FKSK9kR3zPbelInI8+qnvj9jfe20GJFWpHEKMWd4xOPOY5JlYul2wAreyirwSruWBhHS27Xldk8dbaYOaEaDVPV0LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/kWkkbmrltnBtrx8NBvAz1+rOEKDdIpQvhhrQJ4+Qt4=; b=X+BWel8nDyz6ODdUk52q234fTZVzm8FkYYUEoAi7Ske+wLrhrNeCxwXeji4qFJ0vWcIk7jBW+xUYHmKI3Q+vlFFzF6+klw1nvusXD4FDt4jkK/aWjhO7RxzWbw0dS+YA7JE48PDloc9JQe6BuzvrqkRfMCH2YdITh2Zw+tw/XOQBYSFz2eeV9uz0csfGqyashm7CvmEKIO1ZRHQHa/2TD+eKdyjgDst0b/T4ch8GFc5kgmqYdpx3VC4bIDUCe/7jV1HIM37UAFIuME743Bqio+0jZV+voPhBjy0Z642KUNITwCDsZKvnFa2JMcgefYzV4jjDq0UanNJIR+lnDhS0qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/kWkkbmrltnBtrx8NBvAz1+rOEKDdIpQvhhrQJ4+Qt4=; b=gcB74iUOZ6V+CcCZldqRQ1gTY5Q/v7HV/sfgb1BBeX+SqacVwCLnGEj1wBkFXHHuRVeBcYY72ryDd3+YCFsf6ZRm1T/6lGjbdStmQGjHrsCg947L604Xoyk9ii3fTTTOfJ+F7uawNDN23pwSg8STGyp9tP0k8m9iHsf8hGk5B/+huRl138igaO3hJK8VFo0qtJr1aH5lvYNLmiTIzS6jHJIJBL6e6YoBvfXYO2DdLWV0FuU+TUoNbWYxOKIwXokwwGyZxSFeslnMy3H6V1iwNbWfNZRvNaZlgQoYnnwLPyek2Oxw1z5OUasJWx3u3xR4OyPNDONpZOTZydcxS1txZw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2c::6) by YT4PR01MB11571.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:152::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 14:57:38 +0000 Received: from YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM ([fe80::bbfa:179f:fdc8:b15d]) by YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM ([fe80::bbfa:179f:fdc8:b15d%7]) with mapi id 15.21.0428.011; Mon, 21 Sep 2026 14:57:38 +0000 Message-ID: Date: Mon, 21 Sep 2026 10:57:36 -0400 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb: use the selected thread's LWP ID when reading Linux procfs files To: Matthieu Longo Cc: "gdb-patches@sourceware.org" References: <20260917201755.589524-1-simon.marchi@efficios.com> <20260917201755.589524-2-simon.marchi@efficios.com_5b6b04a9_release> <016bc26f-7889-4267-9a7e-00d152bca960@arm.com> Content-Language: fr From: Simon Marchi In-Reply-To: <016bc26f-7889-4267-9a7e-00d152bca960@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YQBPR0101CA0073.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:4::6) To YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2c::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YQXPR01MB5418:EE_|YT4PR01MB11571:EE_ X-MS-Office365-Filtering-Correlation-Id: ad9856f2-ca14-486f-166e-08df17f0ad41 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|376014|366016|23010399003|13003099007|6133799003|10067099003|56012099006|4143699003|5023799004|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: TvXepYmhEAM894dtRKvxA6iEIXFQC6Aeau+mIkRl7aLl84KM83I0Fo3R1pDaN0PN0Hdp27JzUWdONSMOwLkBM8oe+b+7Hu41/ZFXqpKHy02OQGHM3LS31+9No7MVXVeCzAEcK91pQtK0XXQDQOxTUZ9fqpZh9CFuH+x7L/2A6k/y0jt+aicjEi9o6H0vI9om9qJMyui/jVH/Dppbf9k6XjT6gIvdr/ToMWvkGFCbn4aEHEQt5bslLjOPpWbWXxilX8Qjyw8crYGB1sOuCr5hHl1ymUHcSWS+wguB0keDeo+WSauREGDDCYX3eAJObDHWFCkcOSjhA8VeShlxO75O4V4OPboQ6mnXPPg7l6oDU+yapNSMnVNZW0FJM8YKQAWBOCxZSNpkT6KdRPW77VWoR/XdZPk7cwmuSO0EsfPnFkhBF9LEcsEaW9Q5ApOAa0r5k9MJcPErWYwQ4nzj0/RAzPOvJCRvH3U9u0q8uS40+Vxq6s7suFvAldipA8Tk2keEE8lITyyIxhqqRzFJcms0iBpZiicQvBAASFTizFVqW7N0QkYPUYB7SO4CAhjnY6ztFy2IaWz67Nnw1jQ5XmWyClwikcdxuaQlm91BMaGt+E4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(13003099007)(6133799003)(10067099003)(56012099006)(4143699003)(5023799004)(18002099003)(22082099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OVV1SzdNTm9oTFZmOXExN3o0Z0kvUjREeVFYVGc0SG93WDZjaDFqMGpLNmFK?= =?utf-8?B?ck84bHpSL3VXQ25Qa21ERmdiL1l6bkEwclpUM3g3bWQzMUNPWnU5SnB1VHBs?= =?utf-8?B?UGxpSldvbEJlUFhKWlVCUE9HMFZzU0RjaU44TDArUWo1RkVXZXZTempuR1dO?= =?utf-8?B?RVJoWlM4VTNVNUFxOUswVmk0SWl0akFidlpIYW5wbEZJOWl4aTFwMHl5WUh6?= =?utf-8?B?clRCZzEzaXJ3cDNMU3dYQ2h0bTRVRHRKTHpNbmkvdjNjbWdiV1FVQzRERHFG?= =?utf-8?B?YTloV09iZ0VJb0FuL3g2T3FYRUJnSGovZWNWRXBVR3ZvN3hOK1lVYVRwYlRr?= =?utf-8?B?MGQ3SFhUcXIxaVZKeTgyYUJMTkVMZzZ0VzBaUXU5VGFGZDNoNGh5UGNYYkV4?= =?utf-8?B?MldiMkJBVEVhRjUrcHhyN1JORk93dTZ6YWFDZjh3cEwycnY1NFdTYjRpemZs?= =?utf-8?B?SlE0c2luQXlQS1N2U3JlMEZBbTh1aVU2VkhoT2VoOXFDTmF1S04rdzI0RFFq?= =?utf-8?B?UmI0VjR3L2U1ZVRsQUtad0lrNjZjUmtkQ09sV2dyY0dzd0g4SmFuMnowZUpz?= =?utf-8?B?Ym9tdVJnM0d2TEVKbXdQTmtoTVZpc0tlUG1OeTF5N3JNYW4yalR2NE1OWEI3?= =?utf-8?B?Umk3RHBXTVhyeFhVanB1YVV4d2g2VTZXdFBHcVRId0Y4YnJUQmhkNmJWdWdK?= =?utf-8?B?Y0wrRjRYZFVjUFU5OWhHZ3B6N245bWcyWTk1Y2ZLMzVSSUtrWkpPNHNKUmpW?= =?utf-8?B?NlVXamZPMG9JUkdqdTVObVdyL01rWkxiZ0Y4ZUttcjJiK09ibGNPem93eWxv?= =?utf-8?B?TjZKUjdpRkIwazRjbWI2SjZhelloZjYyK01LcGRFSDF4djRvd05lQWJrU3Ba?= =?utf-8?B?Mm40NVhWVFQ2cTdsVmMvb2o4ai9xVzJwUmdHOEhhWm00SWlEQWFXejdXSTdB?= =?utf-8?B?V2tmSEZ6TncxNU5VcmwwTkdFaFg5TnQwZUFJdDhGdDM2QUpCRU5CSFlDVTg2?= =?utf-8?B?UklBVG5RbjRtMURud2lDSkdsdllEZzdoTjNKSkZCWFdJeVFJUEcvRzdOcDJt?= =?utf-8?B?UzZPcUdpeTZwUGkrUXk0WHdyTTU4UytBNDE2Nnp1STVxblRRdnhuUTdhTzZQ?= =?utf-8?B?TU5BUE45UFE1VW1ldk1NdW55M1Vhdk5LTU01bnBZTGFuN1JEdlFncVJsWjFR?= =?utf-8?B?bHlNQmlRN2ZPL0w1NUFxNXVKcUhVemQvdGw2NWlnRDBXNm01NmMwWkhYZzlW?= =?utf-8?B?YnBOeCtPdmFoZzhMWkJhU0c0bGZ0UGVNUGl5T1Y5WkF3dVdaK0NYZUNoZ3Bp?= =?utf-8?B?TGQwdGNoL2kvcnhqUHNoLzcrQjdLa2d6S1BSWU9SZkxVeGUvMG9scDNSMzFa?= =?utf-8?B?SEowU2JJRkhEL1I1Q1BVWXJ1UEZOc0R1bi9Fc0VqWVhieFlaaE55RmpTQkFO?= =?utf-8?B?NFEwdFFBaFc3QTlRSDhLYUNlcGVSdnJjcVozNlN6cVk0UWZzN2lYSEw5OXVz?= =?utf-8?B?K0R1RStoTngzTjZTUXY2elBSRjZ1OUQzSXJjTlMxK3liSzh6aHhQaWRYV205?= =?utf-8?B?VjhxTDVRcGxsa0ExbzhoSzdOOC9XTXpnSkNDc2NMVnBPaGNLMjRHcXVNb3A0?= =?utf-8?B?UGZvczlRM2hLMXVQM2xTVmk2QU16UU8rSXZrdG96ZUFidFFmUnR0WmtRVTh5?= =?utf-8?B?VkpLRmhhWjZub04yY200ZXlFeUNKcUYrMTRZdXQ1RjdBNEZxK0FPWThzRXcw?= =?utf-8?B?NGhuQUFxSTNMUnBGWi9HN2tKaHUxMU1XS3dzY2toVXpSOEtXSk52UmxXalFa?= =?utf-8?B?bk5uWURRK09mSmpPU0RNZXVrTTA4OE9mV3daMSsydUFFTVpGa0c0UStxSTdy?= =?utf-8?B?clJiN1dIWU1QMXVJWm1YVnRGUnpLN0JCTTBFNzB2ak5VdDdCMlBYb3ozV2FH?= =?utf-8?B?Vy9FdHI5ZjdHTS9LMTlvZFhHTnNBcGRZYnpFWUd4N0w2NFVSbGdGVjhKelkx?= =?utf-8?B?cjRWemp1UHZYRDNFRG1Temk0WU84VnBVRHJNKzhra1cycSthZHhBK28reiti?= =?utf-8?B?MDhtQnhBZ2xhRkJkbTZiamhPRXBUYnc4Szc0K0tmaDVHUU9nNUVlVFpiVFVQ?= =?utf-8?B?OVpIK0VUOEhUOUpiSm5adWlLOUxlSXFhTjlFbmdGaDA4VGZuYjFZMVM0bFRn?= =?utf-8?B?azNaNUxhV3FpNXRvTGsxektQY1JLalV2ck1abjN1WVdtNHkyWEN1cTFBWE9P?= =?utf-8?B?Vm0vRk5mYXNDazVZaGJsVmhBdHlMQkJjR081WmZhQTMwR3hrUHNwa2NhWjQr?= =?utf-8?B?MmdVenpUcHFoR2h5cmxhOEhuK1o5bmNuVFV5QTZTYUxpK21SV21VQT09?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad9856f2-ca14-486f-166e-08df17f0ad41 X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB5418.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 14:57:37.8607 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6VjLSAd0bBfkvQuzmSfzCUBhOL2zxTCTmU7ScW5ZR7JTCnhSz9GmK8AyjhxCGamiFBXbLiMDmsOCjbfitZtsyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT4PR01MB11571 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 9/21/26 10:26 AM, Matthieu Longo wrote: > On 18/09/2026 13:21, Simon Marchi wrote: >> On Linux, /proc/ is keyed by the thread-group leader PID. When the >> leader has exited, some /proc//... entries become unavailable even >> though another thread is still alive. This can happen, for instance, >> when the main thread calls pthread_exit() and another thread continues >> the execution (existing test: gcore-stale-thread, renamed below). >> >> This causes GDB to fail to read procfs entries such as cmdline, cwd, >> exe, maps, and smaps when it builds the paths from the inferior pid >> after the thread-group leader has exited. >> >> A /proc/ entry exists for every live LWP of the process, and for >> the entries listed above its contents are the same as those of >> /proc/. Fix this by building the procfs paths from the LWP id of a >> thread GDB believes is alive, rather than from the inferior pid. >> >> Add get_ptid_for_slash_proc, which returns the PTID to read from, and >> use it in places that read /proc: >> >> - linux_info_proc >> - linux_process_address_in_memtag_page >> - linux_find_memory_regions_full >> - linux_fill_prpsinfo >> - linux_address_in_shadow_stack_mem_range >> >> linux_vsyscall_range_raw also reads /proc, but I did not change it, as >> it uses a different pattern, "/proc//task//maps". It could in >> theory suffer from the same problem. >> >> The thread is chosen with any_non_exited_thread_of_inferior, which gives >> preference to the selected thread. I think this is actually a good >> feature. Some entries in /proc (like stat and status) show some >> thread-specific content, so this lets the user pick which thread "info >> proc" reports on. Most entries are per-process, the choice of thread >> makes no difference for them. >> >> linux_fill_prpsinfo is an exception to the above. It populates the >> NT_PRPSINFO note of a core file, which the kernel (for kernel-generated >> core files) fills in from the thread group leader, even when that leader >> is a zombie: >> >> https://elixir.bootlin.com/linux/v7.2.5/source/fs/binfmt_elf.c#L1901 >> >> To keep GDB-generated cores looking like kernel-generated ones, it keeps >> reading stat and status from the leader's entry, so the values taken >> from those match what the kernel would write (stat and status are still >> readable when the thread is zombie). Only the cmdline is read from a >> live LWP, since trying to read that one from a zombie leader doesn't >> work. This mirrors the kernel's fill_psinfo function, which takes the >> program name and arguments from the mm of the thread doing the dump: >> >> https://elixir.bootlin.com/linux/v7.2.5/source/fs/binfmt_elf.c#L1530-L1539 >> >> This also fixes a bug, in that core dumps produced while the leader is >> zombie would be missing the NT_PRPSINFO note. linux_fill_prpsinfo would >> read an empty string from cmdline and return false. A user-visible >> consequence of that is that loading back the core would not show the >> expected "Core was generated by..." line. >> >> This is still a best-effort: GDB's view of the thread list may be stale, >> so the thread selected to do the /proc accesses may actually have >> exited but GDB does not know it. >> >> Since the entry "info proc" reads is no longer necessarily that of the >> thread group leader, replace its "process " header with: >> >> Reading /proc for process >> >> or, when the LWP differs from the PID: >> >> Reading /proc for process (LWP ) >> >> Since "info proc" now stores the pid given on the command line in a >> ptid_t, whose pid field is an int, reject a value that would not survive >> the conversion, rather than printing one value and reading /proc for >> another. >> >> Update gdb.base/info-proc.exp for the new header. >> >> Rename gdb.threads/gcore-stale-thread.{exp,c} to >> gdb.threads/thread-leader-exited.{exp,c} and modify it in a few ways: >> >> - give the program a second worker thread >> >> - check that we're able to read /proc on Linux even when the leader has >> exited (and is selected) >> >> - check that "info proc stat" reports each worker thread's own LWP id >> in its "Process:" field, confirming that "info proc" prioritizes the >> selected thread >> >> - load the generated core back to verify that we see the "Core was >> generated by ..." line, and therefore the NT_PRPSINFO note was >> generated >> >> - enable non-stop using the usual save_vars / append to GDBFLAGS >> pattern, which fixes a pre-existing bug of not being able to run the >> test on the native-extended-gdbserver board. >> >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 >> Change-Id: I1e6ccfae90551b8e96a5644b51c7652bbda593fa >> Co-Authored-By: Matthieu Longo > It looks good to me. > > I ran the 2 patches on the top of master, on both AArch64 and x86_64 on our internal CI and I found > 2 failing tests on AArch64: step-over-process-exit.exp and missing-thread.exp. > I re-ran them manually and both of them are passing. > This has nothing to do with your patch, but are those tests known for being flickering ? > > This is the logs for step-over-process-exit.exp: > ``` > maint show target-non-stop > Whether the target is always in non-stop mode is auto (currently on). > (gdb) next > [Thread 0xfffff7fc0020 (LWP 291431) (id 1) exited] > [New LWP 291431 (id 3)] > [Thread 0xfffff7e0f120 (LWP 292049) (id 2) exited] > warning: error removing breakpoint 0 at 0xaaaaaaaa087c > Command aborted, thread exited. > Cannot remove breakpoints because program is no longer writable. > Further execution is probably impossible. > (gdb) [Inferior 1 (process 291431) exited normally] > FAIL: gdb.threads/step-over-process-exit.exp: which=other: next (timeout) This one looks odd, you get a notification that LWP 291431 exits, then a notification that there is a "new" LWP 291431. It sounds like maybe we processed an exit event for that thread, followed by another event, that made GDB think there was a new thread. > ``` > VS when it passed: > ``` > maint show target-non-stop > Whether the target is always in non-stop mode is auto (currently on). > (gdb) next > [LWP 1540 (id 2) exited] > [Inferior 1 (process 1539) exited normally] > (gdb) PASS: gdb.threads/step-over-process-exit.exp: which=other: next > ``` > It looks like there is an issue while removing breakpoints. At first glance, I would say that there > is a race condition in the test when thread 1 exist before 2. > And this, somehow creates a time-out ? > > Regarding logs for missing-thread.exp: > ``` > continue > Continuing. > [New Thread 217413.218469 (id 2)] > [Thread 217413.218469 (id 2) exited] > warning: command aborted, Thread 217413.218469 unexpectedly exited after signal stop event > Remote communication error. Target disconnected: error while reading: Connection reset by peer. > (gdb) FAIL: gdb.replay/missing-thread.exp: non_stop=on: missing 1 thread log: replay_with_log: continue > ``` > vs when it passed: > ``` > continue > Continuing. > [New Thread 1692.1693 (id 2)] > > Thread 2 "missing-thread" received signal SIGTRAP, Trace/breakpoint trap. > 0x0000fffff7eb6ce0 in clock_nanosleep () from /lib/aarch64-linux-gnu/libc.so.6 > (gdb) PASS: gdb.replay/missing-thread.exp: non_stop=on: with unmodified log: replay_with_log: continue > ``` The message in the failure in this one sounds like the remote side (gdbreplay) suddenly exiting. Not sure if it's just exiting cleanly because it's done, or if it's crashing. Some threads tests are known to be racy, ideally it would take someone to invest time in each of them to understand and fix the race conditions. Could you please open some bugs to document those failures in Bugzilla (if there aren't already)? Simon