[PATCH 0/2] Add warning if the native target is not supported

[PATCH 0/2] Add warning if the native target is not supported

[Guinevere Larsen]

Recently I was trying to conduct a new-user test, to figure out what
things were stumbling blocks, and one of the users had a macbook.  The
user on their own would not have been able to understand what was the
reason that they couldn't execute the inferior to debug it.

This series aims to make it a little more obvious, by warning the user
when GDB starts that there is no native target, and instructs the user
on how to get a list of supported architectures, to know what they'll be
able to remotely debug.

Guinevere Larsen (2):
  gdb: introduce command "info architecture"
  gdb: add warning when no native target is available

 gdb/NEWS            |  4 ++++
 gdb/arch-utils.c    | 28 ++++++++++++++++++++++++++++
 gdb/doc/gdb.texinfo |  5 +++++
 gdb/main.c          |  5 +++++
 4 files changed, 42 insertions(+)


base-commit: af68056244a6c84ee296db5560d8d53f4e829261
-- 
2.51.0

[PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

There is no convenient way to tell a user how to check which
architectures are supported by their build of GDB.  This hasn't really
been a problem, but now that GDB isn't ported to Apple's new CPU
architectures, a user could run into a situation where they're trying to
debug an unsupported CPU.

This commit adds a way to list supported architectures, and filter them
using a regular expression.  No test is added because I couldn't think
of a good way to verify functionality when we can't control the
configure line.
---
 gdb/NEWS            |  4 ++++
 gdb/arch-utils.c    | 28 ++++++++++++++++++++++++++++
 gdb/doc/gdb.texinfo |  5 +++++
 3 files changed, 37 insertions(+)

diff --git a/gdb/NEWS b/gdb/NEWS
index 64e35f1a438..8d87e2473f7 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -45,6 +45,10 @@ maintenance test-remote-args ARGS
   Test splitting and joining of inferior arguments ARGS as they would
   be split and joined when being passed to a remote target.
 
+info architectures [REGEXP]
+  List CPU microarchitectures supported by this build of GDB.  If
+  REGEXP is provided, filter to microarchitectures that match it.
+
 * Changed commands
 
 maintenance info program-spaces
diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c
index 8e3f79089d4..4367e26c02b 100644
--- a/gdb/arch-utils.c
+++ b/gdb/arch-utils.c
@@ -682,6 +682,28 @@ static enum bfd_endian default_byte_order = BFD_ENDIAN_UNKNOWN;
    "set arch" command.  */
 static std::vector<const char *> arches;
 
+/* Implementation of "info architectures" command.  */
+
+static void
+info_architectures_command (const char *args, int from_tty)
+{
+  bool filtered = false;
+  if (args != nullptr && args[0] != '\0')
+    {
+      char *re_err = re_comp (args);
+      if (re_err != nullptr)
+	error (_("Invalid regexp: %s"), re_err);
+      filtered = true;
+    }
+  for (const char *s : arches)
+    {
+      if (s == nullptr)
+	break;
+      if (!filtered || re_exec (s))
+	gdb_printf ("%s\n", s);
+    }
+}
+
 void
 initialize_current_architecture (void)
 {
@@ -767,6 +789,12 @@ initialize_current_architecture (void)
 			      &setlist, &showlist);
     add_alias_cmd ("processor", architecture_cmds.set, class_support, 1,
 		   &setlist);
+    add_info ("architectures", info_architectures_command,
+	      _("List supported CPU microarchitectures.\n\
+\n\
+Usage: info architectures [REGEXP]\n\
+If REGEXP is supplied, list supported microarchitectures that match the\n\
+regular expresion.  Otherwise list all supported microarchitectures."));
   }
 }
 
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 854f22b612e..a4576ca3703 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -23428,6 +23428,11 @@ Show the current target architecture.
 @kindex show processor
 These are alias commands for, respectively, @code{set architecture}
 and @code{show architecture}.
+
+@item info architectures
+@item info architectures @var{regexp}
+List architectures supported by GDB. If @var{regexp} is provided, filter
+results through the regular expression, otherwise list all architectures.
 @end table
 
 @menu
-- 
2.51.0

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Thu, 6 Nov 2025, Guinevere Larsen wrote:

> There is no convenient way to tell a user how to check which
> architectures are supported by their build of GDB.  This hasn't really
> been a problem, but now that GDB isn't ported to Apple's new CPU
> architectures, a user could run into a situation where they're trying to
> debug an unsupported CPU.

 Umm, doesn't `set architecture' do the right job?

(gdb) set architecture
Requires an argument. Valid arguments are ARC600, A6, ARC601, ARC700, A7, ARCv2, EM, HS, arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, iwmmxt, iwmmxt2, armv5tej, armv6, armv6kz, armv6t2, armv6k, armv7, armv6-m, armv6s-m, armv7e-m, armv8-a, armv8-r, armv8-m.base, armv8-m.main, armv8.1-m.main, armv9-a, arm_any, avr, avr:1, avr:2, avr:25, avr:3, avr:31, avr:35, avr:4, avr:5, avr:51, avr:6, avr:100, avr:101, avr:102, avr:103, avr:104, avr:105, avr:106, avr:107, bfin, cris, crisv32, cris:common_v10_v32, csky, csky:ck510, csky:ck610, csky:ck801, csky:ck802, csky:ck803, csky:ck807, csky:ck810, csky:ck860, csky:any, frv, tomcat, simple, fr550, fr500, fr450, fr400, fr300, ft32, ft32b, h8300, h8300h, h8300s, h8300hn, h8300sn, h8300sx, h8300sxn, hppa1.0, i386, i386:x86-64, i386:x64-32, i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, iq2000, iq10, lm32, m16c, m32c, m32r, m32rx, m32r2, m68hc11, m68hc12, m68hc12:HCS12, m68k, m68k:68000, m68k:68008, m68k
 :68010, m68k:68020, m68k:68030, m68k:68040, m68k:68060, m68k:cpu32, m68k:fido, m68k:isa-a:nodiv, m68k:isa-a, m68k:isa-a:mac, m68k:isa-a:emac, m68k:isa-aplus, m68k:isa-aplus:mac, m68k:isa-aplus:emac, m68k:isa-b:nousp, m68k:isa-b:nousp:mac, m68k:isa-b:nousp:emac, m68k:isa-b, m68k:isa-b:mac, m68k:isa-b:emac, m68k:isa-b:float, m68k:isa-b:float:mac, m68k:isa-b:float:emac, m68k:isa-c, m68k:isa-c:mac, m68k:isa-c:emac, m68k:isa-c:nodiv, m68k:isa-c:nodiv:mac, m68k:isa-c:nodiv:emac, m68k:5200, m68k:5206e, m68k:5307, m68k:5407, m68k:528x, m68k:521x, m68k:5249, m68k:547x, m68k:548x, m68k:cfv4e, mep, h1, c5, MicroBlaze, mn10300, am33, am33-2, moxie, msp:14, MSP430, MSP430x11x1, MSP430x12, MSP430x13, MSP430x14, MSP430x15, MSP430x16, MSP430x20, MSP430x21, MSP430x22, MSP430x23, MSP430x24, MSP430x26, MSP430x31, MSP430x32, MSP430x33, MSP430x41, MSP430x42, MSP430x43, MSP430x44, MSP430x46, MSP430x47, MSP430x54, MSP430X, n1, n1h, n1h_v2, n1h_v3, n1h_v3m, or1k, or1knd, rl78, rs6000:6000, rs6000:rs1, rs60
 00:rsc, rs6000:rs2, powerpc:common, powerpc:common64, powerpc:603, powerpc:EC603e, powerpc:604, powerpc:403, powerpc:601, powerpc:620, powerpc:630, powerpc:a35, powerpc:rs64ii, powerpc:rs64iii, powerpc:7400, powerpc:e500, powerpc:e500mc, powerpc:e500mc64, powerpc:MPC8XX, powerpc:750, powerpc:titan, powerpc:vle, powerpc:e5500, powerpc:e6500, rx, rx:v2, rx:v3, s12z, s390:31-bit, s390:64-bit, sh, sh2, sh2e, sh-dsp, sh3, sh3-nommu, sh3-dsp, sh3e, sh4, sh4a, sh4al-dsp, sh4-nofpu, sh4-nommu-nofpu, sh4a-nofpu, sh2a, sh2a-nofpu, sh2a-nofpu-or-sh4-nommu-nofpu, sh2a-nofpu-or-sh3-nommu, sh2a-or-sh4, sh2a-or-sh3e, sparc, sparc:sparclet, sparc:sparclite, sparc:v8plus, sparc:v8plusa, sparc:sparclite_le, sparc:v9, sparc:v9a, sparc:v8plusb, sparc:v9b, sparc:v8plusc, sparc:v9c, sparc:v8plusd, sparc:v9d, sparc:v8pluse, sparc:v9e, sparc:v8plusv, sparc:v9v, sparc:v8plusm, sparc:v9m, sparc:v8plusm8, sparc:v9m8, tic6x, v850:old-gcc-abi, v850e3v5:old-gcc-abi, v850e2v4:old-gcc-abi, v850e2v3:old-gcc-abi, v8
 50e2:old-gcc-abi, v850e1:old-gcc-abi, v850e:old-gcc-abi, v850:rh850, v850e3v5, v850e2v4, v850e2v3, v850e2, v850e1, v850e, v850-rh850, vax, xstormy16, xtensa, z80, z80-strict, z80-full, r800, gbz80, z180, z80n, ez80-z80, ez80-adl, aarch64, aarch64:llp64, aarch64:ilp32, aarch64:armv8-r, alpha, alpha:ev4, alpha:ev5, alpha:ev6, bpf, xbpf, ia64-elf64, ia64-elf32, Loongarch64, Loongarch32, mips, mips:3000, mips:3900, mips:4000, mips:4010, mips:4100, mips:4111, mips:4120, mips:4300, mips:4400, mips:4600, mips:4650, mips:5000, mips:5400, mips:5500, mips:5900, mips:6000, mips:7000, mips:8000, mips:9000, mips:10000, mips:12000, mips:14000, mips:16000, mips:16, mips:mips5, mips:isa32, mips:isa32r2, mips:isa32r3, mips:isa32r5, mips:isa32r6, mips:isa64, mips:isa64r2, mips:isa64r3, mips:isa64r5, mips:isa64r6, mips:sb1, mips:loongson_2e, mips:loongson_2f, mips:gs464, mips:gs464e, mips:gs264e, mips:octeon, mips:octeon+, mips:octeon2, mips:octeon3, mips:xlr, mips:interaptiv-mr2, mips:allegrex, mips:
 micromips, riscv, riscv:rv64, riscv:rv32, tilegx, tilegx32, auto.
(gdb) 

Or am I missing something?  Of course adding filtering might be useful, 
especially if the list so large as in my quoted example, but the change 
description suggests there's no listing facility available.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

On 11/6/25 8:24 PM, Maciej W. Rozycki wrote:
> On Thu, 6 Nov 2025, Guinevere Larsen wrote:
>
>> There is no convenient way to tell a user how to check which
>> architectures are supported by their build of GDB.  This hasn't really
>> been a problem, but now that GDB isn't ported to Apple's new CPU
>> architectures, a user could run into a situation where they're trying to
>> debug an unsupported CPU.
>   Umm, doesn't `set architecture' do the right job?
>
> (gdb) set architecture
> Requires an argument. Valid arguments are ARC600, A6, ARC601, ARC700, A7, ARCv2, EM, HS, arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, iwmmxt, iwmmxt2, armv5tej, armv6, armv6kz, armv6t2, armv6k, armv7, armv6-m, armv6s-m, armv7e-m, armv8-a, armv8-r, armv8-m.base, armv8-m.main, armv8.1-m.main, armv9-a, arm_any, avr, avr:1, avr:2, avr:25, avr:3, avr:31, avr:35, avr:4, avr:5, avr:51, avr:6, avr:100, avr:101, avr:102, avr:103, avr:104, avr:105, avr:106, avr:107, bfin, cris, crisv32, cris:common_v10_v32, csky, csky:ck510, csky:ck610, csky:ck801, csky:ck802, csky:ck803, csky:ck807, csky:ck810, csky:ck860, csky:any, frv, tomcat, simple, fr550, fr500, fr450, fr400, fr300, ft32, ft32b, h8300, h8300h, h8300s, h8300hn, h8300sn, h8300sx, h8300sxn, hppa1.0, i386, i386:x86-64, i386:x64-32, i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, iq2000, iq10, lm32, m16c, m32c, m32r, m32rx, m32r2, m68hc11, m68hc12, m68hc12:HCS12, m68k, m68k:68000, m68k:68008, m68k
>   :68010, m68k:68020, m68k:68030, m68k:68040, m68k:68060, m68k:cpu32, m68k:fido, m68k:isa-a:nodiv, m68k:isa-a, m68k:isa-a:mac, m68k:isa-a:emac, m68k:isa-aplus, m68k:isa-aplus:mac, m68k:isa-aplus:emac, m68k:isa-b:nousp, m68k:isa-b:nousp:mac, m68k:isa-b:nousp:emac, m68k:isa-b, m68k:isa-b:mac, m68k:isa-b:emac, m68k:isa-b:float, m68k:isa-b:float:mac, m68k:isa-b:float:emac, m68k:isa-c, m68k:isa-c:mac, m68k:isa-c:emac, m68k:isa-c:nodiv, m68k:isa-c:nodiv:mac, m68k:isa-c:nodiv:emac, m68k:5200, m68k:5206e, m68k:5307, m68k:5407, m68k:528x, m68k:521x, m68k:5249, m68k:547x, m68k:548x, m68k:cfv4e, mep, h1, c5, MicroBlaze, mn10300, am33, am33-2, moxie, msp:14, MSP430, MSP430x11x1, MSP430x12, MSP430x13, MSP430x14, MSP430x15, MSP430x16, MSP430x20, MSP430x21, MSP430x22, MSP430x23, MSP430x24, MSP430x26, MSP430x31, MSP430x32, MSP430x33, MSP430x41, MSP430x42, MSP430x43, MSP430x44, MSP430x46, MSP430x47, MSP430x54, MSP430X, n1, n1h, n1h_v2, n1h_v3, n1h_v3m, or1k, or1knd, rl78, rs6000:6000, rs6000:rs1, rs60
>   00:rsc, rs6000:rs2, powerpc:common, powerpc:common64, powerpc:603, powerpc:EC603e, powerpc:604, powerpc:403, powerpc:601, powerpc:620, powerpc:630, powerpc:a35, powerpc:rs64ii, powerpc:rs64iii, powerpc:7400, powerpc:e500, powerpc:e500mc, powerpc:e500mc64, powerpc:MPC8XX, powerpc:750, powerpc:titan, powerpc:vle, powerpc:e5500, powerpc:e6500, rx, rx:v2, rx:v3, s12z, s390:31-bit, s390:64-bit, sh, sh2, sh2e, sh-dsp, sh3, sh3-nommu, sh3-dsp, sh3e, sh4, sh4a, sh4al-dsp, sh4-nofpu, sh4-nommu-nofpu, sh4a-nofpu, sh2a, sh2a-nofpu, sh2a-nofpu-or-sh4-nommu-nofpu, sh2a-nofpu-or-sh3-nommu, sh2a-or-sh4, sh2a-or-sh3e, sparc, sparc:sparclet, sparc:sparclite, sparc:v8plus, sparc:v8plusa, sparc:sparclite_le, sparc:v9, sparc:v9a, sparc:v8plusb, sparc:v9b, sparc:v8plusc, sparc:v9c, sparc:v8plusd, sparc:v9d, sparc:v8pluse, sparc:v9e, sparc:v8plusv, sparc:v9v, sparc:v8plusm, sparc:v9m, sparc:v8plusm8, sparc:v9m8, tic6x, v850:old-gcc-abi, v850e3v5:old-gcc-abi, v850e2v4:old-gcc-abi, v850e2v3:old-gcc-abi, v8
>   50e2:old-gcc-abi, v850e1:old-gcc-abi, v850e:old-gcc-abi, v850:rh850, v850e3v5, v850e2v4, v850e2v3, v850e2, v850e1, v850e, v850-rh850, vax, xstormy16, xtensa, z80, z80-strict, z80-full, r800, gbz80, z180, z80n, ez80-z80, ez80-adl, aarch64, aarch64:llp64, aarch64:ilp32, aarch64:armv8-r, alpha, alpha:ev4, alpha:ev5, alpha:ev6, bpf, xbpf, ia64-elf64, ia64-elf32, Loongarch64, Loongarch32, mips, mips:3000, mips:3900, mips:4000, mips:4010, mips:4100, mips:4111, mips:4120, mips:4300, mips:4400, mips:4600, mips:4650, mips:5000, mips:5400, mips:5500, mips:5900, mips:6000, mips:7000, mips:8000, mips:9000, mips:10000, mips:12000, mips:14000, mips:16000, mips:16, mips:mips5, mips:isa32, mips:isa32r2, mips:isa32r3, mips:isa32r5, mips:isa32r6, mips:isa64, mips:isa64r2, mips:isa64r3, mips:isa64r5, mips:isa64r6, mips:sb1, mips:loongson_2e, mips:loongson_2f, mips:gs464, mips:gs464e, mips:gs264e, mips:octeon, mips:octeon+, mips:octeon2, mips:octeon3, mips:xlr, mips:interaptiv-mr2, mips:allegrex, mips:
>   micromips, riscv, riscv:rv64, riscv:rv32, tilegx, tilegx32, auto.
> (gdb)
>
> Or am I missing something?  Of course adding filtering might be useful,
> especially if the list so large as in my quoted example, but the change
> description suggests there's no listing facility available.

Well, I wouldn't say we have a listing facility. using Set Architecture 
without an argument may list them, but that is an error message, rather 
than a command to do that, which is why I don't think it is a convenient 
way to tell a user to check for support. You could achieve the same if 
you asked for completion, but again, not a "listing facility" in the 
sense of telling a user to check.

This is mostly inspired by the second patch, where the error tells you 
how to get a list of supported CPUs, and I think that having a hint that 
uses an incorrect command is not great.

>
>    Maciej
>
>

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Fri, 7 Nov 2025, Guinevere Larsen wrote:

> > Or am I missing something?  Of course adding filtering might be useful,
> > especially if the list so large as in my quoted example, but the change
> > description suggests there's no listing facility available.
> 
> Well, I wouldn't say we have a listing facility. using Set Architecture
> without an argument may list them, but that is an error message, rather than a
> command to do that, which is why I don't think it is a convenient way to tell
> a user to check for support. You could achieve the same if you asked for
> completion, but again, not a "listing facility" in the sense of telling a user
> to check.

 We could reword output from `set architecture' so as not to suggest the 
use without an argument is invalid.

 In any case the listing facility must not be an `info' subcommand, as 
these are meant for showing the state of the debuggee, while the set of 
architectures supported is a property of the given instance of GDB itself, 
and therefore suitable for the `set'/`show' commands.  So if a new command 
it would have to be `show architecture list' or suchlike.

 BTW is there a way to globally disable styling by default?  I find it 
irritating (it distracts me and hurts my eyes) as I do having to type:

(gdb) set style enabled off

every time.  Placing the command in $HOME/.config/gdb/gdbinit or 
$HOME/.gdbinit does nothing, the welcome message is still a disturbing 
mixture of colours.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Hannes Domani]

 Am Freitag, 7. November 2025 um 16:52:39 MEZ hat Maciej W. Rozycki <macro@orcam.me.uk> Folgendes geschrieben:

> On Fri, 7 Nov 2025, Guinevere Larsen wrote:
> 
> > > Or am I missing something?  Of course adding filtering might be useful,
> > > especially if the list so large as in my quoted example, but the change
> > > description suggests there's no listing facility available.
> >
> > Well, I wouldn't say we have a listing facility. using Set Architecture
> > without an argument may list them, but that is an error message, rather than a
> > command to do that, which is why I don't think it is a convenient way to tell
> > a user to check for support. You could achieve the same if you asked for
> > completion, but again, not a "listing facility" in the sense of telling a user
> > to check.
> 
> We could reword output from `set architecture' so as not to suggest the
> use without an argument is invalid.
> 
> In any case the listing facility must not be an `info' subcommand, as
> these are meant for showing the state of the debuggee, while the set of
> architectures supported is a property of the given instance of GDB itself,
> and therefore suitable for the `set'/`show' commands.  So if a new command
> it would have to be `show architecture list' or suchlike.
> 
> BTW is there a way to globally disable styling by default?  I find it
> irritating (it distracts me and hurts my eyes) as I do having to type:
> 
> (gdb) set style enabled off
> 
> every time.  Placing the command in $HOME/.config/gdb/gdbinit or
> $HOME/.gdbinit does nothing, the welcome message is still a disturbing
> mixture of colours.

Try putting it into $HOME/.gdbearlyinit


Hannes

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Fri, 7 Nov 2025, Hannes Domani wrote:

> > BTW is there a way to globally disable styling by default?  I find it
> > irritating (it distracts me and hurts my eyes) as I do having to type:
> > 
> > (gdb) set style enabled off
> > 
> > every time.  Placing the command in $HOME/.config/gdb/gdbinit or
> > $HOME/.gdbinit does nothing, the welcome message is still a disturbing
> > mixture of colours.
> 
> Try putting it into $HOME/.gdbearlyinit

 This helps, thanks!  Obviously I've missed the addition of this fairly 
recent facility.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On 11/7/25 12:51 PM, Maciej W. Rozycki wrote:
> On Fri, 7 Nov 2025, Guinevere Larsen wrote:
>
>>> Or am I missing something?  Of course adding filtering might be useful,
>>> especially if the list so large as in my quoted example, but the change
>>> description suggests there's no listing facility available.
>> Well, I wouldn't say we have a listing facility. using Set Architecture
>> without an argument may list them, but that is an error message, rather than a
>> command to do that, which is why I don't think it is a convenient way to tell
>> a user to check for support. You could achieve the same if you asked for
>> completion, but again, not a "listing facility" in the sense of telling a user
>> to check.
>   We could reword output from `set architecture' so as not to suggest the
> use without an argument is invalid.
>
>   In any case the listing facility must not be an `info' subcommand, as
> these are meant for showing the state of the debuggee,

I disagree, in my opinion, this new command would function basically 
just like "info unwinder", giving information on how GDB is able to 
interact with the inferior.

>   while the set of
> architectures supported is a property of the given instance of GDB itself,
> and therefore suitable for the `set'/`show' commands.  So if a new command
> it would have to be `show architecture list' or suchlike.

My understanding is that set/show commands are mostly used for when the 
user could change something, and the point of this command is showing 
the user the compilation options that were used, there's no changes that 
a user could do.

-- 
Cheers,
Guinevere Larsen
It/she

[-- Attachment #2: Type: text/html, Size: 2561 bytes --]

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Thu, 27 Nov 2025, Guinevere Larsen wrote:

> >   We could reword output from `set architecture' so as not to suggest the
> > use without an argument is invalid.
> > 
> >   In any case the listing facility must not be an `info' subcommand, as
> > these are meant for showing the state of the debuggee,
> 
> I disagree, in my opinion, this new command would function basically just like
> "info unwinder", giving information on how GDB is able to interact with the
> inferior.

 Is it the semantics documented in the manual since forever (search for it 
and when it appeared there) that you disagree with?  I don't know what 
`info unwinder' is about, but maybe someone got it wrong too and it should 
be a `show' subcommand instead.

> >   while the set of
> > architectures supported is a property of the given instance of GDB itself,
> > and therefore suitable for the `set'/`show' commands.  So if a new command
> > it would have to be `show architecture list' or suchlike.
> 
> My understanding is that set/show commands are mostly used for when the user
> could change something, and the point of this command is showing the user the
> compilation options that were used, there's no changes that a user could do.

 Same as with:

(gdb) show version

-- it can't be changed by the user and there's no corresponding `set' 
command.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

On 11/27/25 5:00 PM, Maciej W. Rozycki wrote:
> On Thu, 27 Nov 2025, Guinevere Larsen wrote:
>
>>>    We could reword output from `set architecture' so as not to suggest the
>>> use without an argument is invalid.
>>>
>>>    In any case the listing facility must not be an `info' subcommand, as
>>> these are meant for showing the state of the debuggee,
>> I disagree, in my opinion, this new command would function basically just like
>> "info unwinder", giving information on how GDB is able to interact with the
>> inferior.
>   Is it the semantics documented in the manual since forever (search for it
> and when it appeared there) that you disagree with?  I don't know what
> `info unwinder' is about, but maybe someone got it wrong too and it should
> be a `show' subcommand instead.

I know that this is what the manual and the help text say about "info", 
but that's not how the command has been used since at least the 1999 commit:

commit c906108c21474dfb4ed285bcc0ac6fe02cd400cc (tag: gdb-4_18-branchpoint)
Author: Stan Shebs <shebs@codesourcery.com>
Date:   Fri Apr 16 01:35:26 1999 +0000

     Initial creation of sourceware repository

in which the commands "info copying" and "info warranty" were added. The 
show version of these commands were only added in 2011.

>>>    while the set of
>>> architectures supported is a property of the given instance of GDB itself,
>>> and therefore suitable for the `set'/`show' commands.  So if a new command
>>> it would have to be `show architecture list' or suchlike.
>> My understanding is that set/show commands are mostly used for when the user
>> could change something, and the point of this command is showing the user the
>> compilation options that were used, there's no changes that a user could do.
>   Same as with:
>
> (gdb) show version
>
> -- it can't be changed by the user and there's no corresponding `set'
> command.
>
>    Maciej
>

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Thu, 27 Nov 2025, Guinevere Larsen wrote:

> >   Is it the semantics documented in the manual since forever (search for it
> > and when it appeared there) that you disagree with?  I don't know what
> > `info unwinder' is about, but maybe someone got it wrong too and it should
> > be a `show' subcommand instead.
> 
> I know that this is what the manual and the help text say about "info", but
> that's not how the command has been used since at least the 1999 commit:
> 
> commit c906108c21474dfb4ed285bcc0ac6fe02cd400cc (tag: gdb-4_18-branchpoint)
> Author: Stan Shebs <shebs@codesourcery.com>
> Date:   Fri Apr 16 01:35:26 1999 +0000
> 
>     Initial creation of sourceware repository
> 
> in which the commands "info copying" and "info warranty" were added. The show
> version of these commands were only added in 2011.

 I can't help with that.  Also clearly the inconsistency has been noticed 
and fixed (with the old commands retained for backwards compatibility).  
That doesn't mean we ought to create more inconsistencies.

 NB the repo goes far beyond 1999 (refer commit 1730ec6b1848 for earlier 
history), although those older commits are often inconsistent owing to CVS 
conversion issues, and there were clear attempts to get this sorted long 
before and somehow lost in the mist of history.  E.g. commit a7d50b0adfcd, 
commit a3bb247ef0a2, commit 440d9834411b, and many more (search for "info 
warranty").  FWIW myself I've used GDB since 1994.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

On 11/28/25 6:20 AM, Maciej W. Rozycki wrote:
> On Thu, 27 Nov 2025, Guinevere Larsen wrote:
>
>>>    Is it the semantics documented in the manual since forever (search for it
>>> and when it appeared there) that you disagree with?  I don't know what
>>> `info unwinder' is about, but maybe someone got it wrong too and it should
>>> be a `show' subcommand instead.
>> I know that this is what the manual and the help text say about "info", but
>> that's not how the command has been used since at least the 1999 commit:
>>
>> commit c906108c21474dfb4ed285bcc0ac6fe02cd400cc (tag: gdb-4_18-branchpoint)
>> Author: Stan Shebs <shebs@codesourcery.com>
>> Date:   Fri Apr 16 01:35:26 1999 +0000
>>
>>      Initial creation of sourceware repository
>>
>> in which the commands "info copying" and "info warranty" were added. The show
>> version of these commands were only added in 2011.
>   I can't help with that.  Also clearly the inconsistency has been noticed
> and fixed (with the old commands retained for backwards compatibility).
> That doesn't mean we ought to create more inconsistencies.
>
>   NB the repo goes far beyond 1999 (refer commit 1730ec6b1848 for earlier
> history), although those older commits are often inconsistent owing to CVS
> conversion issues, and there were clear attempts to get this sorted long
> before and somehow lost in the mist of history.  E.g. commit a7d50b0adfcd,
> commit a3bb247ef0a2, commit 440d9834411b, and many more (search for "info
> warranty").  FWIW myself I've used GDB since 1994.
>
>    Maciej
>
I ended up talking to Andrew off-list about this, and he provided what I 
think should be a better solution than either of our suggestions. We 
could update the help text for the "set architecture" command to list 
the options instead of introducing a new command.

I'll work on this and send a v2 when I can

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Eli Zaretskii]

> From: Guinevere Larsen <guinevere@redhat.com>
> Cc: Guinevere Larsen <guinevere@redhat.com>
> Date: Thu,  6 Nov 2025 16:45:13 -0300
> 
> There is no convenient way to tell a user how to check which
> architectures are supported by their build of GDB.  This hasn't really
> been a problem, but now that GDB isn't ported to Apple's new CPU
> architectures, a user could run into a situation where they're trying to
> debug an unsupported CPU.
> 
> This commit adds a way to list supported architectures, and filter them
> using a regular expression.  No test is added because I couldn't think
> of a good way to verify functionality when we can't control the
> configure line.
> ---
>  gdb/NEWS            |  4 ++++
>  gdb/arch-utils.c    | 28 ++++++++++++++++++++++++++++
>  gdb/doc/gdb.texinfo |  5 +++++
>  3 files changed, 37 insertions(+)

Thanks.  The documentation parts are okay (with one nit, see below),
but I'm struggling to understand what you mean by "CPU
microarchitectures".  And without examples, I cannot even guess.
Would it be possible to expand on that in the manual, or at least
provide a could of examples of what the output will look like?

> +@item info architectures
> +@item info architectures @var{regexp}
> +List architectures supported by GDB. If @var{regexp} is provided, filter
                                      ^^
Two spaces there.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

On 11/7/25 4:46 AM, Eli Zaretskii wrote:
>> From: Guinevere Larsen <guinevere@redhat.com>
>> Cc: Guinevere Larsen <guinevere@redhat.com>
>> Date: Thu,  6 Nov 2025 16:45:13 -0300
>>
>> There is no convenient way to tell a user how to check which
>> architectures are supported by their build of GDB.  This hasn't really
>> been a problem, but now that GDB isn't ported to Apple's new CPU
>> architectures, a user could run into a situation where they're trying to
>> debug an unsupported CPU.
>>
>> This commit adds a way to list supported architectures, and filter them
>> using a regular expression.  No test is added because I couldn't think
>> of a good way to verify functionality when we can't control the
>> configure line.
>> ---
>>   gdb/NEWS            |  4 ++++
>>   gdb/arch-utils.c    | 28 ++++++++++++++++++++++++++++
>>   gdb/doc/gdb.texinfo |  5 +++++
>>   3 files changed, 37 insertions(+)
> Thanks.  The documentation parts are okay (with one nit, see below),
> but I'm struggling to understand what you mean by "CPU
> microarchitectures".  And without examples, I cannot even guess.
> Would it be possible to expand on that in the manual, or at least
> provide a could of examples of what the output will look like?

A CPU architecture is something like "arm" or "x86". The 
microarchitecture is changes within that architecture, like "armv3", 
"armv4", "armv3m" and so on.

I'm not sure how to expand on this in the manual, and considering this 
is how "set architecture" works, I just thought it would be good to be 
more specific, but I can just call it "architecture" instead, if you 
think it is better.

>
>> +@item info architectures
>> +@item info architectures @var{regexp}
>> +List architectures supported by GDB. If @var{regexp} is provided, filter
Fixed
>                                        ^^
> Two spaces there.
>
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
>

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Eli Zaretskii]

> Date: Fri, 7 Nov 2025 10:41:18 -0300
> Cc: gdb-patches@sourceware.org
> From: Guinevere Larsen <guinevere@redhat.com>
> 
> On 11/7/25 4:46 AM, Eli Zaretskii wrote:
> > Thanks.  The documentation parts are okay (with one nit, see below),
> > but I'm struggling to understand what you mean by "CPU
> > microarchitectures".  And without examples, I cannot even guess.
> > Would it be possible to expand on that in the manual, or at least
> > provide a could of examples of what the output will look like?
> 
> A CPU architecture is something like "arm" or "x86". The 
> microarchitecture is changes within that architecture, like "armv3", 
> "armv4", "armv3m" and so on.
> 
> I'm not sure how to expand on this in the manual

Just add the above text there, it will already be a huge step forward.
Thanks.

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Fri, 7 Nov 2025, Guinevere Larsen wrote:

> > Thanks.  The documentation parts are okay (with one nit, see below),
> > but I'm struggling to understand what you mean by "CPU
> > microarchitectures".  And without examples, I cannot even guess.
> > Would it be possible to expand on that in the manual, or at least
> > provide a could of examples of what the output will look like?
> 
> A CPU architecture is something like "arm" or "x86". The microarchitecture is
> changes within that architecture, like "armv3", "armv4", "armv3m" and so on.

 I don't think it's correct, not at least it's the definition I've been 
taught.  In my dictionary microarchitecture is a particular implementation 
of a given architecture with all its properties, such as instruction 
latencies, the execution units and pipeline stages, the existence or the 
lack of specific pipeline dependencies, and so on and so on.

 I can't comment on ARM particulars as I'm not very familiar with them, 
but offhand "armv3" or "armv4" seem to me to be architecture revisions 
rather than microarchitectures.

 In MIPS terms MIPS is the target architecture, MIPS32r2 is a particular 
architecture revision ("mips:isa32r2" in terms of `set architecture') and 
24Kf or 74Kf are microarchitectures, both implementing the MIPS32r2 
architecture.

 Cf. <https://en.wikipedia.org/wiki/Microarchitecture> for an overview.

 I think the GDB manual has been pretty correct in its "architecture" term
usage.

  Maciej

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Guinevere Larsen]

On 11/7/25 11:25 PM, Maciej W. Rozycki wrote:
> On Fri, 7 Nov 2025, Guinevere Larsen wrote:
>
>>> Thanks.  The documentation parts are okay (with one nit, see below),
>>> but I'm struggling to understand what you mean by "CPU
>>> microarchitectures".  And without examples, I cannot even guess.
>>> Would it be possible to expand on that in the manual, or at least
>>> provide a could of examples of what the output will look like?
>> A CPU architecture is something like "arm" or "x86". The microarchitecture is
>> changes within that architecture, like "armv3", "armv4", "armv3m" and so on.
>   I don't think it's correct, not at least it's the definition I've been
> taught.  In my dictionary microarchitecture is a particular implementation
> of a given architecture with all its properties, such as instruction
> latencies, the execution units and pipeline stages, the existence or the
> lack of specific pipeline dependencies, and so on and so on.
>
>   I can't comment on ARM particulars as I'm not very familiar with them,
> but offhand "armv3" or "armv4" seem to me to be architecture revisions
> rather than microarchitectures.
>
>   In MIPS terms MIPS is the target architecture, MIPS32r2 is a particular
> architecture revision ("mips:isa32r2" in terms of `set architecture') and
> 24Kf or 74Kf are microarchitectures, both implementing the MIPS32r2
> architecture.
>
>   Cf. <https://en.wikipedia.org/wiki/Microarchitecture> for an overview.
>
>   I think the GDB manual has been pretty correct in its "architecture" term
> usage.
>
>    Maciej
>
Ah, I guess I must have misunderstood microarchitecture somewhere along 
the way. So, would it be correct for me to describe the command as 
listing the "architectures" that GDB supports?

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 1/2] gdb: introduce command "info architecture"

[Maciej W. Rozycki]

On Thu, 27 Nov 2025, Guinevere Larsen wrote:

> Ah, I guess I must have misunderstood microarchitecture somewhere along the
> way. So, would it be correct for me to describe the command as listing the
> "architectures" that GDB supports?

 Yes, I think we'll best stick to our current nomenclature.

  Maciej

[PATCH 2/2] gdb: add warning when no native target is available

[Guinevere Larsen]

When a user starts GDB, they have no way of knowing if native debugging
will be supported or not.  This is most relevant for Mac users, since
GDB hasn't been ported to Apple's CPUs yet.

This patch adds a warning if, after initializing all files, GDB was
unable to find an appropriate native target for the session, informing
the user that they will only be able to debug remotely.
---
 gdb/main.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/main.c b/gdb/main.c
index 58a744bb2b7..1aa6e85d1d7 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -1211,6 +1211,11 @@ captured_main_1 (struct captured_main_args *context)
   tmp_warn_preprint.reset ();
   warning_pre_print = "\n";
 
+  if (get_native_target () == nullptr)
+    warning (_("No native target, only remote debugging is supported.\n"
+	       "Use \"%ps\" to check which architectures are supported."),
+	    styled_string (command_style.style (), "info architecture"));
+
   /* Read and execute the system-wide gdbinit file, if it exists.
      This is done *before* all the command line arguments are
      processed; it sets global parameters, which are independent of
-- 
2.51.0

Re: [PATCH 2/2] gdb: add warning when no native target is available

[Eli Zaretskii]

> From: Guinevere Larsen <guinevere@redhat.com>
> Cc: Guinevere Larsen <guinevere@redhat.com>
> Date: Thu,  6 Nov 2025 16:45:14 -0300
> 
> +  if (get_native_target () == nullptr)
> +    warning (_("No native target, only remote debugging is supported.\n"
> +	       "Use \"%ps\" to check which architectures are supported."),
> +	    styled_string (command_style.style (), "info architecture"));

Would we also say "Native debugging is supported" in the opposite
case?

Thanks.

Re: [PATCH 2/2] gdb: add warning when no native target is available

[Guinevere Larsen]

On 11/7/25 4:48 AM, Eli Zaretskii wrote:
>> From: Guinevere Larsen <guinevere@redhat.com>
>> Cc: Guinevere Larsen <guinevere@redhat.com>
>> Date: Thu,  6 Nov 2025 16:45:14 -0300
>>
>> +  if (get_native_target () == nullptr)
>> +    warning (_("No native target, only remote debugging is supported.\n"
>> +	       "Use \"%ps\" to check which architectures are supported."),
>> +	    styled_string (command_style.style (), "info architecture"));
> Would we also say "Native debugging is supported" in the opposite
> case?
>
> Thanks.
>
When you debug an inferior without connecting to a gdbserver, you are 
doing native debugging, but I don't think it makes sense to warn the 
user that native debugging is supported since that is the default 
behavior of GDB, if that is what  you mean with this email.

-- 
Cheers,
Guinevere Larsen
It/she

Re: [PATCH 2/2] gdb: add warning when no native target is available

[Eli Zaretskii]

> Date: Fri, 7 Nov 2025 10:24:15 -0300
> Cc: gdb-patches@sourceware.org
> From: Guinevere Larsen <guinevere@redhat.com>
> 
> On 11/7/25 4:48 AM, Eli Zaretskii wrote:
> >> From: Guinevere Larsen <guinevere@redhat.com>
> >> Cc: Guinevere Larsen <guinevere@redhat.com>
> >> Date: Thu,  6 Nov 2025 16:45:14 -0300
> >>
> >> +  if (get_native_target () == nullptr)
> >> +    warning (_("No native target, only remote debugging is supported.\n"
> >> +	       "Use \"%ps\" to check which architectures are supported."),
> >> +	    styled_string (command_style.style (), "info architecture"));
> > Would we also say "Native debugging is supported" in the opposite
> > case?
> >
> > Thanks.
> >
> When you debug an inferior without connecting to a gdbserver, you are 
> doing native debugging, but I don't think it makes sense to warn the 
> user that native debugging is supported since that is the default 
> behavior of GDB, if that is what  you mean with this email.

Then perhaps I don't understand the purpose of the patch.  I thought
it was part of showing the information about GDB at the start of a
session.  In that case, I think it's good to let user know that this
GDB supports native debugging, and also tell them if it doesn't.
Apologies if I misunderstood.

Re: [PATCH 2/2] gdb: add warning when no native target is available

[Guinevere Larsen]

On 11/7/25 11:21 AM, Eli Zaretskii wrote:
>> Date: Fri, 7 Nov 2025 10:24:15 -0300
>> Cc: gdb-patches@sourceware.org
>> From: Guinevere Larsen <guinevere@redhat.com>
>>
>> On 11/7/25 4:48 AM, Eli Zaretskii wrote:
>>>> From: Guinevere Larsen <guinevere@redhat.com>
>>>> Cc: Guinevere Larsen <guinevere@redhat.com>
>>>> Date: Thu,  6 Nov 2025 16:45:14 -0300
>>>>
>>>> +  if (get_native_target () == nullptr)
>>>> +    warning (_("No native target, only remote debugging is supported.\n"
>>>> +	       "Use \"%ps\" to check which architectures are supported."),
>>>> +	    styled_string (command_style.style (), "info architecture"));
>>> Would we also say "Native debugging is supported" in the opposite
>>> case?
>>>
>>> Thanks.
>>>
>> When you debug an inferior without connecting to a gdbserver, you are
>> doing native debugging, but I don't think it makes sense to warn the
>> user that native debugging is supported since that is the default
>> behavior of GDB, if that is what  you mean with this email.
> Then perhaps I don't understand the purpose of the patch.  I thought
> it was part of showing the information about GDB at the start of a
> session.  In that case, I think it's good to let user know that this
> GDB supports native debugging, and also tell them if it doesn't.
> Apologies if I misunderstood.
>
The purpose of this patch is to make the user aware that GDB will not 
work as they likely expect.

Most of the GDB usage and explanations that I've seen so far barely 
mention gdbserver, and basically never mention debugging a different 
architecture, so if a user just fires up GDB and it isn't able to debug 
anything natively, that will be highly unexpected, hence emitting a warning.

-- 
Cheers,
Guinevere Larsen
It/she