From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WakpETAG6GiyDCYAWB0awg (envelope-from ) for ; Thu, 09 Oct 2025 15:00:00 -0400 Received: by simark.ca (Postfix, from userid 112) id 3F7161E0B6; Thu, 09 Oct 2025 15:00:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 283601E047 for ; Thu, 09 Oct 2025 14:59:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9045C3858D21 for ; Thu, 9 Oct 2025 18:59:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9045C3858D21 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id 3359D3858D21 for ; Thu, 9 Oct 2025 18:59:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3359D3858D21 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3359D3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.53 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760036367; cv=none; b=fNyRL9vDBoN1KAh/eomvPXPieb2xMTjPyL1IwWycXG4EHLwXKX/uGcSJ3cGB1I/QnNw7VFwn2U9VcQmxW877D4FiQj0w0yxdztYbqjfjmp2Wez/n+3q33WZE8scZzrdfEbeHukeKy2Rb+/qQcWAkQSzz3I4sLRaQUfJj1SuO0Qc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760036367; c=relaxed/simple; bh=LvJ9CW6zGws+1Xt81mRsZC0HUNqg1nqXdODryiYihTY=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=lr8Fshl60SIrRqOHRX2VDRww03YqK/DyOZai4Vp4vK3Pf6f25wK1Ni4kqhFG3+Oeds7Ng8BqxtsD+TxOhEas564ia3Zsjw0MO+MeNyePkUmNZxhSzq1BJFcub4URHn2RdAHUzvDY9yz+mcGlsKYVPLhSwHCco+eQlYzzYdvj32M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3359D3858D21 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-46e504975dbso8129565e9.1 for ; Thu, 09 Oct 2025 11:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760036366; x=1760641166; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g8U18g69wm6fwT+ch8Qp14KyiCmdMfwDDi/dpTRCkW8=; b=mI3tTDwWTs9lfI20Sxqf5b0qXH8Z5yAmW/AuPyDdWfVS/W/gc3FDoo7/0CQvBtLCrY 2Fl7clS4c9OhEK6+lvd7mbxziml88UPQRZyvyNRXpPrao5b3eysyyv+U+nXMO4fn9Pj1 K93PfWTbbYh+OSTFjFZTDjkq/zp4hiRW8AGXFJajSlEEOHZZoVELFiNtq5P3wB+ZRN4c 3Bfp33SPhxNA1TRQzBvPoXkGTjcDH434r/Kt+NZSUfvl94KiY9upsYxj9Y/1k4+I1fiC 0x1LrU7Y/xasqc4vsGXa94tkv8RY5bL2AeJUD7p9T6OkUJu5VXYVsLdMf3g5IywUFL+m 727A== X-Forwarded-Encrypted: i=1; AJvYcCXfy959uokawZ2Rg2UCBd2C3I0wnUtsoblYP3Ecp7FHgB+O3WUn4u6i/9RV1n41VHBZiZHRI2OWT9ga/w==@sourceware.org X-Gm-Message-State: AOJu0Yw0f0X9Hz39o4q3tXhC6g4pQm71pubqkyA7+Wm8vv6KZuA1yVIR TuhVDLsbb6Ja9jLyQEzXlGDV0kGXcN/NddROeySAc6EKnGbMEGK/Avpv X-Gm-Gg: ASbGncv5b0G/kRrsigJFmZuwd1f0+FsDMaO9vIWUrqLoRB4kLAX7Hawbps0u8lCXrJu 9GtZk6H3oO3CRD2xgdnLUNYTkgm+E0WOrRo2C19ijj2x4vl3nMv0PzzN6W3AYkUtAagxo3ucSfg xNqnNmyQODuJ2r6d6SynKJapHiJQssjgTfzHHc2SKO91oh9FXA/JaTHUUck9hnsJF5XU+m7Pkn2 V+X0jmR1L0QAYeduZz4oemsHkl046+l8exGInHvEq7ViNYzN+GLZ6fk2qFmsH9C7vZDqXMnfaHQ Wc2IIIZhlac6ue859T/Nk8s4JEs5Kf3QFFgKtA5b6a2f2qdWBYPfS5zRVdp64qN0A/T87iFqW6X mAzHoB0rbiCeksao6QkFnnzd7DN1ds4SA+xNq/r19oYCq13qBK4NYl88SvTloVU8ZHlTogyuyaY L0Vli+AjBbo4w= X-Google-Smtp-Source: AGHT+IEzvuP8h3pP/F5gkjXwsmOq6xF/vJ5L2O0n0inQFbF7L8NgBX3yTlz+US7K9UvaVoLCToeD7g== X-Received: by 2002:a5d:64c4:0:b0:3ed:a43d:8eba with SMTP id ffacd0b85a97d-4266e8de141mr5420491f8f.52.1760036365592; Thu, 09 Oct 2025 11:59:25 -0700 (PDT) Received: from ?IPV6:2001:8a0:faca:8200:e89:492b:2cfc:3f42? ([2001:8a0:faca:8200:e89:492b:2cfc:3f42]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce57cc03sm411925f8f.4.2025.10.09.11.59.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Oct 2025 11:59:25 -0700 (PDT) Message-ID: <7461a0b8-846a-4969-aeb6-7eac08732037@palves.net> Date: Thu, 9 Oct 2025 19:59:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: notify of inferior switch when needed from 'thread' command To: Andrew Burgess , gdb-patches@sourceware.org References: From: Pedro Alves Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 Hi! On 2025-10-08 09:48, Andrew Burgess wrote: > What this message is talking about is this behaviour: > > (gdb) info threads > Id Target Id Frame > 1.1 Thread 0xf7dbc700 (LWP 818430) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6 > 1.2 Thread 0xf7dbbb40 (LWP 818433) "thr" 0xf7fd0579 in __kernel_vsyscall () > 1.3 Thread 0xf73ffb40 (LWP 818434) "thr" breakpt () at thr.c:19 > 2.1 Thread 0xf7dbc700 (LWP 818456) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6 > 2.2 Thread 0xf7dbbb40 (LWP 818457) "thr" breakpt () at thr.c:19 > * 2.3 Thread 0xf73ffb40 (LWP 818458) "thr" breakpt () at thr.c:19 > (gdb) inferior 1 > [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)] > [Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))] > #0 0xf7eb2888 in clone () from /lib/libc.so.6 > (gdb) thread 2.2 > [Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))] > #0 breakpt () at thr.c:19 > 19 while (stop) > (gdb) > > Notice that when we switch from thread 2.3 to 1.1 using the 'inferior > 1' command, GDB tells us that the inferior has changed, and that the > thread has changed (and also that the frame has changed). > > But, when we switch from 1.1 to 2.2 using the 'thread 2.2' command, we > are only told about the thread change. > > The 'Switching to inferior ...' line includes some useful information, > the process PID and the executable name, and I think it is a shame > that these are not presented when using the 'thread' command to switch > inferior. AMD and Intel have been having discussions about settling on how to expose GPU lane debugging in GDB for the past year, and this very detail came up there. (There was a presentation/BoF about the topic at the Cauldron and videos/slides are already up: https://conf.gnu-tools-cauldron.org/opo25/talk/FN7FKL/ ) For lane debugging support, we're going to propose a new "lane" command (along with 'info lanes', 'lane find', 'break foo lane N' etc.), where "lane" is new level of execution context. Currently an inferior has threads. And with lane debugging, a thread has lanes. So inferior has threads, thread has lanes. A lane has a fully-qualified ID like "I.T.L" (inferior.thread.lane), just like threads have a fully qualified ID like "I.T". For the issue at hand, it works like this: (gdb) inferior 1 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)] [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)] [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])] #0 do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; (gdb) thread 7 [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)] [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])] #0 do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; (gdb) lane 0 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])] #0 do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; Note this is just reusing the logic of the current behavior you observed with "inferior" and "thread". There is a logic/pattern to it that I think is the right balance. Let me explain. When you do "inferior 1", GDB also switches to some thread of inferior 1. Reusing your example, if GDB didn't print about what thread it switched to, and just said: (gdb) inferior 1 [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)] #0 0xf7eb2888 in clone () from /lib/libc.so.6 then the user would have no way to know what thread is now current, and would be forced to issue the "thread" command to get it. So that's why current GDB prints the "Switch to thread" part too: (gdb) inferior 1 [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)] [Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))] #0 0xf7eb2888 in clone () from /lib/libc.so.6 This however, does not apply when you use the "thread" command instead of the "inferior" command, as in, you are not _forced_ to use the "inferior" command. That is because in that case, the "Switching to thread 2.2" part, as in your example: (gdb) thread 2.2 [Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))] #0 breakpt () at thr.c:19 19 while (stop) ... that "thread 2.2" part already tells you which inferior it is GDB switched to. It's inferior 2, from "2.2", which is "I.T". That is why in my example above, when I switch to lane 0 with the "lane" command, GDB only needs to tell me about the lane switch and not the "inferior" and "thread" switching: (gdb) lane 0 [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])] #0 do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; >From "lane 1.7.0", I already know the inferior (1) and the thread (7), so GDB doesn't need to say it. I _can_ use the "inferior" and "thread" commands to get more information if I want, but I'm not _forced_ to. So the current logic, extended to lanes, is I think simple -- when you switch to an execution object using a "FOO" command, then GDB informs you about the current FOO it switched to, as well as any finer execution object context below FOO. I.e., - if you use the "inferior" command, GDB tells you about "inferior", "thread" and "lane" (if lanes exist). - if you use the "thread" command, GDB tells you about "thread" and "lane" (if lanes exist). - if you use the "lane" command, GDB tells you about "lane". This reduces noise for a set of core commands that are used all the time. When you're focused on switching threads around to debug something, you don't need to be told what is the current program the inferior is running. IMHO, it ends up being noise after a short while, like: (gdb) lane 0 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)] [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)] [Switching to lane 1.7.0 (AMDGPU Lane 1:2:1:1/0 (0,0,0)[0,0,0])] #0 do_an_addition (a=1, b=2, out=0x7ffee3e00000) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; (gdb) lane 1 [Switching to inferior 1 [process 3286570] (/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.rocm/simple/simple)] [Switching to thread 1.7 (AMDGPU Wave 1:2:1:1 (0,0,0)/0)] [Switching to lane 1.7.1 (AMDGPU Lane 1:2:1:1/1 (0,0,0)[0,0,1])] #0 do_an_addition (a=, b=, out=) at /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.cpp:24 24 *out = a + b; etc., etc. IOW, even though you could argue that the "Switching to inferior ..." information could be useful when you use the "thread" command, that is information that the user can easily retrieve with the "inferior" command. I think reducing noise is more important here, especially when we start adding other levels of execution objects, like lanes. (If you happen to have an AMD GPU, you can play with my examples above using this branch: https://github.com/ROCm/ROCgdb/tree/users/palves/lane-debugging) Pedro Alves