From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id t4ZxMCUmyGe7wQUAWB0awg (envelope-from ) for ; Wed, 05 Mar 2025 05:23:33 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=ALS+Sjyd; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A5CEE1E105; Wed, 5 Mar 2025 05:23:33 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FORGED_MUA_MOZILLA, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 E7AA21E08E for ; Wed, 5 Mar 2025 05:23:32 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2BD5F3858D34 for ; Wed, 5 Mar 2025 10:23:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2BD5F3858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1741170212; bh=1SOdOahppobm50NWyx0yfoqtNziWUe+lgx1wX4pNfjg=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ALS+SjydqS09he5f63d3b/GzADvHz7fwZTV+VNikubsIycXfMt5O7RI2W1JLdBIn+ VYSBmzgsrAoO69MF9AXvoJwk5B0VwOd6etFvS0Ht1r97qD2hDCCtGqNXS1JG2DTPxW 2nsw4571BNUWqfFXEFdv0jXdvXf+OULIm/rVfDdA= Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03olkn2080a.outbound.protection.outlook.com [IPv6:2a01:111:f403:2e0d::80a]) by sourceware.org (Postfix) with ESMTPS id 650B63858D26 for ; Wed, 5 Mar 2025 10:22:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 650B63858D26 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 650B63858D26 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1741170168; cv=pass; b=lNR/tXswIHvoXxh8kP4hmh14kRwjCN9xLdbpTKTU446YQkfC4/UVpwYr2MtQ6dYP+PBAMYREyHbl26EviagXjjpL8cSLRnSzewaZVUTDSTg8hTW9ONqn81qAJve8rVbDq4v11Ho0+oCY2xRKf1bT5G81gcaPV4yfUY1Dse2wnxs= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1741170168; c=relaxed/simple; bh=pFiYV6XskJFq5Ag6RoZNNGrRDuSaCxQyjHZpJ59Yx78=; h=DKIM-Signature:Message-ID:Date:From:Subject:To:MIME-Version; b=fkKEypo6XwDBWO64h9sB5b8ofyC0aHr9mjyHwbL2Sf90SuGvBaZPZ9AOmFrRGfIK7kcXMmplWEUYkY4gUiQdDGih8jiIyus7sDRmqhbBC1QQmrIOAtLk/p/d+Z+LE5QqtPRSRmlKDTxO4rPyf4TLZmn5OtM+C7c30ijrwlnkhCQ= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 650B63858D26 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZREfn2DpidTzb3nupVJZ5y+XT0XKVdKyIJ4JD/1xDsgW90tENunbVH7ZngN2/uKmkuiePeaPo9lKv5Yg8qeSsAIVDEikCvYIH356y3E544f4WPlLUxiUN3dPxuW2oejAunHe4Ol8sie4dw17/jHGLxLJ9YuL+wspySrvOuAVVmHEpcIWDo7Rv7imrntWLPFNym9VKqk1nlmEX1kPx+SLTWv4Yh7Pq2nKfD4sBM6lVpy41GGHH3JaHHUYY2kdwvGAMJJ5SoHbDjXdA3RHlK7RbyBPbwhlES1G3ywVETNWtKTpPPyugBZ39Hvqg7Yb2HfEn9vHMiCP/SDDuHZtxBqasA== 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=1SOdOahppobm50NWyx0yfoqtNziWUe+lgx1wX4pNfjg=; b=PYX4XTjlYiC+RzMGZqI/mQfkOQTlZow+q8Ir5r/juNPWT/7qtbKmzpWsWP+2wNfB+LBQhLTbOSJ5ICMyXJNZt+4hlTALnCHNoPcBWLVM0QBTzojKrF1w/dCbiVaFsLkSZiaLLchRPh3k1/IQrD9oN64zxwEdDSGMTFBgjp15Of0FpLa8Kf40tEUx2Hw+Ltr5jgbDDFIqBWpznqEM9XEf1tCI3iJGCMhIk7JX2R+nIm+MqE7vxAwHcnSQP/QM+38vi/4+6S7T5eZIdR9Edf1VS665z74zTZBcGJP1lnndaZbn6IyccA6M0/6AzLQVNm5v2bi63YTGRq5ogFRz9J7SJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB9PR05MB8235.eurprd05.prod.outlook.com (2603:10a6:10:260::21) by DB9PR05MB8108.eurprd05.prod.outlook.com (2603:10a6:10:259::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.17; Wed, 5 Mar 2025 10:22:45 +0000 Received: from DB9PR05MB8235.eurprd05.prod.outlook.com ([fe80::422a:8e43:e486:6e04]) by DB9PR05MB8235.eurprd05.prod.outlook.com ([fe80::422a:8e43:e486:6e04%4]) with mapi id 15.20.8511.017; Wed, 5 Mar 2025 10:22:45 +0000 Message-ID: Date: Wed, 5 Mar 2025 15:22:33 +0500 User-Agent: Mozilla Thunderbird Content-Language: en-US Subject: Multi-threading support on DragonFlyBSD To: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: GVZP280CA0061.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:270::11) To DB9PR05MB8235.eurprd05.prod.outlook.com (2603:10a6:10:260::21) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB9PR05MB8235:EE_|DB9PR05MB8108:EE_ X-MS-Office365-Filtering-Correlation-Id: 1f03b2f2-c5fd-4db6-90b8-08dd5bcfaa69 X-Microsoft-Antispam: BCL:0; ARA:14566002|19110799003|8060799006|15080799006|8022599003|5072599009|7092599003|461199028|6090799003|440099028|3412199025|41001999003|12091999003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VjBzUExzcFhlWkhONVYrMFNoTklHeGU4ck54Ymk3cWd0c1ZZa3NiZXYzTGpT?= =?utf-8?B?TWhPWEdPUWhEcTMrTmQ5WVhMRGN5dmNPWEtYZGZ5ajRHMHE3a0N2ZHhMZFIw?= =?utf-8?B?TmtFMWZVbm50MWRzNk9CNUVxTHZiS3dLV1dSVkMwdHMvZklFV2kzczlhVzda?= =?utf-8?B?MkNCT2crSWZtOG1wQy9ZZVkrc054ZGxudlczekhQOEtlTXB5YkMvbzlPU3lm?= =?utf-8?B?ckxqQ2lHZ0kxcWJCNWNYcWUvK0gzZ2VFSFM2Tk1aZ3Q1RjJlOE9PY0NGVUN3?= =?utf-8?B?RGQxTU83TkswOS9KOTdwOTBCSUFjdUpSQ1dDbzRvdllaTXlpZ0F4M1VQbVF5?= =?utf-8?B?aFpoWWVJMzV5ZjlYV2g2ejhXeUxqdklac3pra1ppUXN3bVBSa3lxSnppcmJM?= =?utf-8?B?cU5vc29jNjZIR3VzT0hrdGJlMHRHRk9KK0RLOFc0QmRQZkJtWE5xbFBOY2NT?= =?utf-8?B?eldLdVBzWVAxUkQzdVlNa0RhZE1QdDRhTjFEZ2VYNzMwbW45SEV4RVFlQkl6?= =?utf-8?B?SVhUYVJvTk1Bc1ZZRTVLQnZrZ2d0NzBXbjRFdnpEUXZiRVhIdUNJQjBpM0JM?= =?utf-8?B?cWF5cTliUjc2b1FSd252UmNiNUJubzNpU01VS0lrYzBTZ1QrL3Z1V0s2VmJm?= =?utf-8?B?Sm5XZDliY1VoUTFnOTUwZVREVUFTTDRoWEJTbE50Zm53ZGRlOXFiczBzT0du?= =?utf-8?B?cnZkbVYxc1ZsRnRBMXRQcUVxcHJNT2hST2kwVlU5TEZSeGVPUE44QWZTWmVF?= =?utf-8?B?YnRndnVmRjgxWEYwbXlMNWlQelJ0QWZmZHZWMGpOM2xpZ2dSRnV1cTdnWTBD?= =?utf-8?B?bUx3bWtobzBSZWg4VVArR0JZeStaM2NlTElKWDQ0anlLaGRDMUludXgyUFVI?= =?utf-8?B?TkQ0WEM3RGpnYU5DWkViTEorTllpSTlUWWxtbWdaUGllbWtFMXFzTnpHamNY?= =?utf-8?B?bnN0LzJ4a3A0Y0U4cUhuR2JkeHhOY3A0eUg4N0RlSHZ2SUFvaldqWVM5RUo2?= =?utf-8?B?WU1JY0drZFpma01TRlFIRDVPYThYSUI4bkZQa0ppdVBybnh3REh1bXNnRFJu?= =?utf-8?B?ZlhOdEVhL2dUOTVtNEhSd1RFYTRkYkJxN3A3RmkvdDdwdG90czZXMUZNQkQr?= =?utf-8?B?V2phWGxiZjFQMFdRbE53QnhkM1h6NU1JbHd1d3YrTXJDc3JzRlkrMU0xN3VH?= =?utf-8?B?MjdBZlVnSVh2NDg1SUJsMmNFTWFpR0VNcDJOQS9OOFYzd2JSeWdJQjFiT3Jp?= =?utf-8?B?MDBDZitNelc2VzZ3aEh5WHlCbU1Ud1ArTHoybnBNSlRhTGtCdmJkUzRacUpU?= =?utf-8?B?bjh4ejF3bEY2V0M3TmozV0lTRWp6eEZiTThFbHNWdy9nRnNEWVFob2l6Vi90?= =?utf-8?B?WERIZ3g4azIvL2lQdXA2eEs2WmVVWERqTVRLVDJCZDQyOUxTclQ0b1g3bndo?= =?utf-8?B?aFJaTTZVbG5MWUNkZGhDL1BQdVZydG1KQ3V4RjdBSk9ha2J4K1FGQnkvLzdE?= =?utf-8?B?bittakxCK2tHY3hQS2NlNGdTNE1rZU5lUDgwVjVXWGduNVk4SUtRaWR1VXI0?= =?utf-8?B?RmMvMzY2YWdoNGN5NHJGQ0crQ0hlMjcyQ1U3eS9uNjNvTWUxNHhhK0VQZ2JQ?= =?utf-8?B?Rk9JSTRzWWg1VjFJRy9KeWRlU2xKb3c9PQ==?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a0FGb1FtVmtQSXM0RmhsaUhCbTk0YzRySU14Y2pRTkFZZFU3N3AxVGFnaVdu?= =?utf-8?B?ZFl1a0ExMEpJZEZzMGVHRnMyRCs3VUFFaUR4alJiK1owZWQyTjMwMDNMcWto?= =?utf-8?B?NnpQeEZ6RFZVUVgwYml3S2lYbml5eU56WnAwanJSQURLVW5NMTA5NGNHbXFo?= =?utf-8?B?VEJJMWF2cmZkWm94c3FVN0FCZTJKQmlKdXA1YWlwOVY1bmRwOHgxaXAzWW4y?= =?utf-8?B?bXVIa21yZFBWb0NWRCsxd3lBT2pZM3Fkd05JeldFRlBYYnFqd3hFcW9MM2Zi?= =?utf-8?B?a3N3aXAxK20rRnE1WFZOd3kySVVzV1BnN0dJc1hsZTY5Z3YyUDNLS1JKQkRC?= =?utf-8?B?VjlUMWM4NG9valA2bXZQYmZLWTlycXoyZGF1Vm9xZlQ4NGVDUG9lYTNEc2Jr?= =?utf-8?B?NkJ2a2JXRUtUZ25hdE9LTTlLVGpiN2ZKdkI3SWFSRHQyN2tScGFvbGNGNUF4?= =?utf-8?B?SzVHbExMQThhc1VlMDhYVjhlUmkzbWdlYkJFNW82a3M4OGtvcDZTUVA0blhY?= =?utf-8?B?UjJSR1psNC9NNnhGcFFZRzU2bkppMmRIcStEQ01oM2tJbmJzYTNtRjdxMnc0?= =?utf-8?B?NkNaemdGdDJ1T1VIcVp6UUhOb1VqbTU4VkJYUUQ5cThWVU9qUHM5TzFrZDlO?= =?utf-8?B?V28xTG5nMkFlOGswR3BycHhpU2hzUyt5NEorY212RE9ScXRaQ1kzSDBaYUMy?= =?utf-8?B?ZzRvNnVmVU1TRFBGUk1hdXNFUzNETmNpdnN2ajNYeE9BWmo0VHVuWTVTTnNz?= =?utf-8?B?cU5KQ2I0Y0JYcDIxU3BZd1RGbjdDWHpIcVhqTjVqWmJzSnZOYW0rM01vT05z?= =?utf-8?B?NDE5N2UrTXQyWEJQUG5KWXFGVktWL2FYRHJRRTlqQjZFT1o2NVlLT0hmM2VJ?= =?utf-8?B?TE9ISWJQUXBWUkZ3K0FmaDhkMHAvNkkzZFh5aXdqeFJOaGx1dzFJT3VXQVRl?= =?utf-8?B?ZERyaitaU0Z0Rzl2Z1E4SWwvTFJwWVMvRER3L203aEhCYnNzWlpKL0tHaGlo?= =?utf-8?B?Q0JuUll6WElic3lWUEZmek9mM0QxQi91bDRJelNlOEp0NEJkd3hWVFEzbUlK?= =?utf-8?B?a1htK2RBSklqV1ZyY2dTVlpKYjIzUGhvUlVZdjlxTVdpcDlVUUVTZlNBYXpp?= =?utf-8?B?TEo5NlEyVVhJV1ljQW5wRzNzU28yeGdXbWRlellBcjVKK2pBdlJpY1k5U21S?= =?utf-8?B?WDRkblR4MEc3OHVVKzUzUllaS2MreVptQSs0SGlUZjdRMVdQRkEzU28zVWtz?= =?utf-8?B?YlVoanE3Vk5aVWhOb29Rd0NwTGg2SjJrY3FITXEvRVFsL3VWMFlqQXdoekhn?= =?utf-8?B?TkpUN0dyYnJzWTB6aC9zcXQvVUoyMnEvbklhVkdvbW9GS3dHUDY1VHdVa0RQ?= =?utf-8?B?MmI1TERsaS9DaHo4bmQ1RVhJZG9wQ2E0MHd4anZBOEVrVjJNaXF3bXJBOGVH?= =?utf-8?B?bGltRm5UU0pSL2RFZXlKNStQTDNaOXRPZWp4ajJoankxSXM3ZjVhZlRJVTJF?= =?utf-8?B?d2hZc0FnR0hNaHVSNkd1cFFwK3htZkpSQmhPakJpNHVyUEtTVkZYOFRhL0U2?= =?utf-8?B?WENZMFh3L2pLbkRlN2tBV0VUT0JYRUpEOHRqb1huNkFxRnhtQVhWOVlnTkEw?= =?utf-8?B?RGRzd09tSFl3Vk9Cdm1FTmw4WGNJRlBVVHl5bE9saWFEWHBVKzZUOEpQQ05N?= =?utf-8?B?bHlEeURlUjNnRTcyOUVLcnl5cE9xd0g5dlRqaDhuTmd6d3BUM1ZHbE55b2l6?= =?utf-8?Q?f1ZOljZSa9JMe3yKBY=3D?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f03b2f2-c5fd-4db6-90b8-08dd5bcfaa69 X-MS-Exchange-CrossTenant-AuthSource: DB9PR05MB8235.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2025 10:22:45.4793 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR05MB8108 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Zigachev via Gdb Reply-To: Sergey Zigachev Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi, I'm trying to enable debugging of multi-threaded programs on DragonFlyBSD using gdb and have several questions. I checked out gdb 15.2 sources, applied out-of-tree patches with native-dependent code implementation for amd64 DragonFlyBSD target. These patches have basic support for enumerating registers, accessing memory etc. All the OS-specific things. Single-thread debugging works well with these patches. However, multiprocess debugging, async and non-stop modes are not implemented. As is any notion of multiple threads in the inferior. My goal is to add missing bits and pieces both in userspace (gdb's nat-dep) and kernelspace (mostly ptrace syscall). I'm at the stage where I have the basics working. I can report events from different threads, suspend/resume single or all threads, inspect TLS variables etc. Schedule-locking mode also supported. My questions concern mostly step-over ("step") command issued to multiple threads, not at once of course. Although I see approx. the same behavior with the "next" command. I wrote a little test C program that has main thread spawning two extra threads running two separate but mostly identical functions. Each function prints message to output, sleeps for several seconds, prints another message, and then returns. Main function waits for both threads to complete. First test run. I put a breakpoint at the start of the first function, run the program and input "step" command until process exits. Essentially I'm debbuging as-if it was a single-thread program. Everything works as expected. By that i mean after each "step" command gdb steps on the next source line until the end of the function. It skips instructions that are part of a single source line, and skips functions that don't have debugging symbols. This is the baseline I'm trying to replicate with stepping over multiple threads. Second test run. Same as the first run but this time I put a breakpoint at the start of both functions. This results in gdb stopping at different threads when I enter "step" command. I observe the following issues: - each source line gets hit several times, I think by the number of asm instructions it implements - gdb stops at functions without debug symbols; sometimes it can step over and continue; sometimes it doesn't if it can't find the end of the function Basically, gdb's acting as if it's running "stepi" command. With trial and error and some printf sprinkled around I came up with a theory why that could happen. Consider this part of the function: > 23 printf("Running thread thr=%d sleep=%d!\n", d->thr_num, d->sleep); > 0x0000000000400b2d <+29>: mov 0xc(%rdi),%edx > 0x0000000000400b30 <+32>: mov $0x400cff,%edi > 0x0000000000400b35 <+37>: xor %eax,%eax > 0x0000000000400b37 <+39>: call 0x4007f0 > > 24 sleep(d->sleep); > 0x0000000000400b3c <+44>: mov 0xc(%rbx),%edi When gdb stops at line 23 and I enter "step" command, it calculates step range thread_info->control.step_range_{start,end}. In this case it will be [0x400b2d-0x400b3c). Then it uses this info to step through asm instructions 4 times transparently to the user. The happy call chain looks like this (infrun.c): - clear_proceed_status_thread *for each thread* - prepare_one_step (infcmd.c) -- this one updates the range - proceed - 4x fetch_inferior_event - stop at next line waiting for input This works for single-thread case because gdb clears thread_info state and then loads range for the *current* thread after clearing. If I return event for a different thread, then its info was cleared and haven't been loaded by gdb before that. Gdb can't recognize this signal and assumes it's a "random signal". It goes downhill from there, I think most consecutive signals become "random". I don't want to track down heisenbugs caused by my dirty hands touching gdb thread state and accidentally braking invariants. Hence this message, any advice is appreciated. My questions: 1. Does my theory make sense? 2. Is it a job of native-dependent code to save/restore thread state before reporting a signal? 3. If yes, what else should I store, per-thread, per-process etc? Thanks, Sergey