* [PATCH 0/2] gdb/alpha: Add target description support and fpcr flags @ 2025-05-26 15:12 Yodel Eldar 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar 2025-05-26 15:12 ` [PATCH 2/2] gdb/alpha: Redefine fpcr with fpcr_flags type Yodel Eldar 0 siblings, 2 replies; 25+ messages in thread From: Yodel Eldar @ 2025-05-26 15:12 UTC (permalink / raw) To: gdb-patches; +Cc: Yodel Eldar Please note that the second patch depends on the first. I initially wrote the target description for use in another project, but when I connected GDB to that project's gdbstub during testing, GDB emitted a warning about rejecting the target description (because it does not support them for Alpha); so, I firstly submit it here (along with some plumbing) and would like to assign the copyright to the FSF for the first time. Target description support will allow Alpha target users to easily specify features of their system at hand that GDB does not have itself; e.g., according to [1] (see below), Alpha 21264 (EV6) does not implement the DNOD flag (bit 47) of the fpcr, contrary to other versions; users can easily inform GDB of this difference by dynamically feeding it their desired target description instead of modifying code for recompilation. Furthermore, Alpha's target-dependent code no longer needs helper functions to get the name or type of a requested register as seen with the removal of alpha_register_name and alpha_register_type in patch one; this separation of concerns improves maintainability over the long run. Converting fpcr from an int64 to a flags type with just a few lines of XML in the second patch demonstrates the power of the target description framework in the convenience that it affords. As a control register, the flags type suits the fpcr better than an int64, because it is a bitfield of flags; admittedly, sixteen flags are a lot, but the fpcr does not appear in "info regs" unless the command is invoked with "float" or "all," and its flags will not appear in the output unless they are set. Lastly, this is my first submission to GDB, and I want to take this opportunity to thank all of the incredible folks who have contributed to this beloved project that has helped me better understand what occurs under the hood of programs over the years. Thank you! I welcome any and all suggestions for improvement. [1] https://www.star.bnl.gov/public/daq/HARDWARE/21264_data_sheet.pdf Yodel Eldar (2): gdb/alpha: Add target description support gdb/alpha: Redefine fpcr with fpcr_flags type gdb/NEWS | 2 + gdb/alpha-tdep.c | 87 ++++++++++++----------- gdb/doc/gdb.texinfo | 42 +++++++++++ gdb/features/Makefile | 1 + gdb/features/alpha-core.xml | 136 ++++++++++++++++++++++++++++++++++++ gdb/features/alpha.c | 111 +++++++++++++++++++++++++++++ gdb/features/alpha.xml | 11 +++ 7 files changed, 351 insertions(+), 39 deletions(-) create mode 100644 gdb/features/alpha-core.xml create mode 100644 gdb/features/alpha.c create mode 100644 gdb/features/alpha.xml -- 2.49.0 ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 1/2] gdb/alpha: Add target description support 2025-05-26 15:12 [PATCH 0/2] gdb/alpha: Add target description support and fpcr flags Yodel Eldar @ 2025-05-26 15:12 ` Yodel Eldar 2025-05-26 16:13 ` Eli Zaretskii ` (2 more replies) 2025-05-26 15:12 ` [PATCH 2/2] gdb/alpha: Redefine fpcr with fpcr_flags type Yodel Eldar 1 sibling, 3 replies; 25+ messages in thread From: Yodel Eldar @ 2025-05-26 15:12 UTC (permalink / raw) To: gdb-patches; +Cc: Yodel Eldar This commit adds target description support for Alpha. The target description obviates the alpha_register_type and alpha_register_name functions in alpha-tdep.c. Removal of alpha_register_reggroup_p was considered but ultimately abandoned, because the "info regs" command would no longer omit the zero, fpcr, and unique registers from its output (they are neither vector nor float types). Register types in the target description annex match the types that the alpha_register_type function returned. The locally defined register_names array was moved out of alpha_register_name and renamed to alpha_register_names as a static global; calls to alpha_register_name have been replaced with direct access of the array. The patch follows the code pattern outlined in the following GDB Internals Wiki entry: https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support --- gdb/NEWS | 2 + gdb/alpha-tdep.c | 87 ++++++++++++++++++++---------------- gdb/doc/gdb.texinfo | 42 ++++++++++++++++++ gdb/features/Makefile | 1 + gdb/features/alpha-core.xml | 88 +++++++++++++++++++++++++++++++++++++ gdb/features/alpha.c | 84 +++++++++++++++++++++++++++++++++++ gdb/features/alpha.xml | 11 +++++ 7 files changed, 276 insertions(+), 39 deletions(-) create mode 100644 gdb/features/alpha-core.xml create mode 100644 gdb/features/alpha.c create mode 100644 gdb/features/alpha.xml diff --git a/gdb/NEWS b/gdb/NEWS index 2e48a00df5a..099c137a16f 100644 --- a/gdb/NEWS +++ b/gdb/NEWS @@ -195,6 +195,8 @@ qXfer:threads:read subsystem to be disabled at configure time, in the form of --disable-gdb-compile. +* The Alpha target now supports target descriptions. + *** Changes in GDB 16 * Support for Nios II targets has been removed as this architecture diff --git a/gdb/alpha-tdep.c b/gdb/alpha-tdep.c index f0272b0e49d..60888a6f475 100644 --- a/gdb/alpha-tdep.c +++ b/gdb/alpha-tdep.c @@ -43,6 +43,9 @@ #include "alpha-tdep.h" #include <algorithm> +#include "target-descriptions.h" +#include "features/alpha.c" + /* Instruction decoding. The notations for registers, immediates and opcodes are the same as the one used in Compaq's Alpha architecture handbook. */ @@ -75,60 +78,38 @@ static const int subq_opcode = 0x10; static const int subq_function = 0x29; \f -/* Return the name of the REGNO register. +/* Alpha registers using their software names. An empty name corresponds to a register number that used to be used for a virtual register. That virtual register has been removed, but the index is still reserved to maintain compatibility with existing remote alpha targets. */ -static const char * -alpha_register_name (struct gdbarch *gdbarch, int regno) +static const char * const alpha_register_names[] = { - static const char * const register_names[] = - { - "v0", "t0", "t1", "t2", "t3", "t4", "t5", "t6", - "t7", "s0", "s1", "s2", "s3", "s4", "s5", "fp", - "a0", "a1", "a2", "a3", "a4", "a5", "t8", "t9", - "t10", "t11", "ra", "t12", "at", "gp", "sp", "zero", - "f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7", - "f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15", - "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23", - "f24", "f25", "f26", "f27", "f28", "f29", "f30", "fpcr", - "pc", "", "unique" - }; - - static_assert (ALPHA_NUM_REGS == ARRAY_SIZE (register_names)); - return register_names[regno]; -} + "v0", "t0", "t1", "t2", "t3", "t4", "t5", "t6", + "t7", "s0", "s1", "s2", "s3", "s4", "s5", "fp", + "a0", "a1", "a2", "a3", "a4", "a5", "t8", "t9", + "t10", "t11", "ra", "t12", "at", "gp", "sp", "zero", + "f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7", + "f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15", + "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23", + "f24", "f25", "f26", "f27", "f28", "f29", "f30", "fpcr", + "pc", "", "unique" +}; +static_assert (ALPHA_NUM_REGS == ARRAY_SIZE (alpha_register_names)); static int alpha_cannot_fetch_register (struct gdbarch *gdbarch, int regno) { - return (strlen (alpha_register_name (gdbarch, regno)) == 0); + return (strlen (alpha_register_names[regno]) == 0); } static int alpha_cannot_store_register (struct gdbarch *gdbarch, int regno) { return (regno == ALPHA_ZERO_REGNUM - || strlen (alpha_register_name (gdbarch, regno)) == 0); -} - -static struct type * -alpha_register_type (struct gdbarch *gdbarch, int regno) -{ - if (regno == ALPHA_SP_REGNUM || regno == ALPHA_GP_REGNUM) - return builtin_type (gdbarch)->builtin_data_ptr; - if (regno == ALPHA_PC_REGNUM) - return builtin_type (gdbarch)->builtin_func_ptr; - - /* Don't need to worry about little vs big endian until - some jerk tries to port to alpha-unicosmk. */ - if (regno >= ALPHA_FP0_REGNUM && regno < ALPHA_FP0_REGNUM + 31) - return builtin_type (gdbarch)->builtin_double; - - return builtin_type (gdbarch)->builtin_int64; + || strlen (alpha_register_names[regno]) == 0); } /* Is REGNUM a member of REGGROUP? */ @@ -1715,11 +1696,39 @@ alpha_software_single_step (struct regcache *regcache) static struct gdbarch * alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) { + tdesc_arch_data_up tdesc_data; + const struct target_desc *tdesc = info.target_desc; + /* Find a candidate among extant architectures. */ arches = gdbarch_list_lookup_by_info (arches, &info); if (arches != NULL) return arches->gdbarch; + if (tdesc == nullptr) + tdesc = tdesc_alpha; + + /* Validate target description. */ + if (tdesc_has_registers (tdesc)) + { + const struct tdesc_feature *feature; + bool valid_p; + + feature = tdesc_find_feature (tdesc, "org.gnu.gdb.alpha.core"); + if (feature == nullptr) + return nullptr; + + tdesc_data = tdesc_data_alloc (); + valid_p = true; + for (int i = 0; i < ALPHA_NUM_REGS; ++i) + valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), i, + alpha_register_names[i]); + + if (!valid_p) + return nullptr; + } + + gdb_assert (tdesc_data != nullptr); + gdbarch *gdbarch = gdbarch_alloc (&info, gdbarch_tdep_up (new alpha_gdbarch_tdep)); alpha_gdbarch_tdep *tdep = gdbarch_tdep<alpha_gdbarch_tdep> (gdbarch); @@ -1756,8 +1765,7 @@ alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) set_gdbarch_pc_regnum (gdbarch, ALPHA_PC_REGNUM); set_gdbarch_fp0_regnum (gdbarch, ALPHA_FP0_REGNUM); - set_gdbarch_register_name (gdbarch, alpha_register_name); - set_gdbarch_register_type (gdbarch, alpha_register_type); + tdesc_use_registers (gdbarch, tdesc, std::move (tdesc_data)); set_gdbarch_cannot_fetch_register (gdbarch, alpha_cannot_fetch_register); set_gdbarch_cannot_store_register (gdbarch, alpha_cannot_store_register); @@ -1822,6 +1830,7 @@ _initialize_alpha_tdep () gdbarch_register (bfd_arch_alpha, alpha_gdbarch_init, NULL); + initialize_tdesc_alpha (); /* Let the user set the fence post for heuristic_proc_start. */ /* We really would like to have both "0" and "unlimited" work, but diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 05f550233fe..216e4b1e51c 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -49316,6 +49316,7 @@ registers using the capitalization used in the description. @menu * AArch64 Features:: +* Alpha Features:: * ARC Features:: * ARM Features:: * i386 Features:: @@ -49622,6 +49623,47 @@ of bytes. Extra registers are allowed in this feature, but they will not affect @value{GDBN}. +@node Alpha Features +@subsection Alpha Features +@cindex target descriptions, Alpha Features + +The @samp{org.gnu.gdb.alpha.core} feature is required for Alpha targets. It +must contain the following 64-bit registers; note that @value{GDBN} uses the +software names for Alpha registers: + +@itemize @minus +@item +@samp{v0}: function return value +@item +@samp{t0} through @samp{t12}: temporary registers +@item +@samp{s0} through @samp{s5}: saved registers +@item +@samp{fp}: frame pointer +@item +@samp{a0} through @samp{a5}: argument registers +@item +@samp{ra}: return address +@item +@samp{at}: assembler temporary register +@item +@samp{gp}: global pointer +@item +@samp{sp}: stack pointer +@item +@samp{zero}: always zero +@item +@samp{f0} through @samp{f30}: floating-point registers +@item +@samp{fpcr}: floating-point control register +@item +@samp{pc}: program counter +@item +@samp{}: an anonymous register for historical purpose +@item +@samp{unique}: PALcode memory slot +@end itemize + @node ARC Features @subsection ARC Features @cindex target descriptions, ARC Features diff --git a/gdb/features/Makefile b/gdb/features/Makefile index 7a8c7999733..750508a85e6 100644 --- a/gdb/features/Makefile +++ b/gdb/features/Makefile @@ -100,6 +100,7 @@ OUTPUTS = $(patsubst %,$(outdir)/%.dat,$(WHICH)) # --enable-targets=all GDB. You can override this by passing XMLTOC # to make on the command line. XMLTOC = \ + alpha.xml \ microblaze-with-stack-protect.xml \ microblaze.xml \ mips-dsp-linux.xml \ diff --git a/gdb/features/alpha-core.xml b/gdb/features/alpha-core.xml new file mode 100644 index 00000000000..9b4d71cf855 --- /dev/null +++ b/gdb/features/alpha-core.xml @@ -0,0 +1,88 @@ +<?xml version="1.0"?> +<!-- Copyright (C) 2025 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. --> + +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> +<feature name="org.gnu.gdb.alpha.core"> + <!-- Integer Registers --> + <reg name="v0" bitsize="64" type="int64"/> + <reg name="t0" bitsize="64" type="int64"/> + <reg name="t1" bitsize="64" type="int64"/> + <reg name="t2" bitsize="64" type="int64"/> + <reg name="t3" bitsize="64" type="int64"/> + <reg name="t4" bitsize="64" type="int64"/> + <reg name="t5" bitsize="64" type="int64"/> + <reg name="t6" bitsize="64" type="int64"/> + <reg name="t7" bitsize="64" type="int64"/> + <reg name="s0" bitsize="64" type="int64"/> + <reg name="s1" bitsize="64" type="int64"/> + <reg name="s2" bitsize="64" type="int64"/> + <reg name="s3" bitsize="64" type="int64"/> + <reg name="s4" bitsize="64" type="int64"/> + <reg name="s5" bitsize="64" type="int64"/> + <reg name="fp" bitsize="64" type="int64"/> + <reg name="a0" bitsize="64" type="int64"/> + <reg name="a1" bitsize="64" type="int64"/> + <reg name="a2" bitsize="64" type="int64"/> + <reg name="a3" bitsize="64" type="int64"/> + <reg name="a4" bitsize="64" type="int64"/> + <reg name="a5" bitsize="64" type="int64"/> + <reg name="t8" bitsize="64" type="int64"/> + <reg name="t9" bitsize="64" type="int64"/> + <reg name="t10" bitsize="64" type="int64"/> + <reg name="t11" bitsize="64" type="int64"/> + <reg name="ra" bitsize="64" type="int64"/> + <reg name="t12" bitsize="64" type="int64"/> + <reg name="at" bitsize="64" type="int64"/> + <reg name="gp" bitsize="64" type="data_ptr"/> + <reg name="sp" bitsize="64" type="data_ptr"/> + <reg name="zero" bitsize="64" type="int64" save-restore="no"/> + + <!-- Floating-Point Registers --> + <reg name="f0" bitsize="64" type="float" group="float"/> + <reg name="f1" bitsize="64" type="float" group="float"/> + <reg name="f2" bitsize="64" type="float" group="float"/> + <reg name="f3" bitsize="64" type="float" group="float"/> + <reg name="f4" bitsize="64" type="float" group="float"/> + <reg name="f5" bitsize="64" type="float" group="float"/> + <reg name="f6" bitsize="64" type="float" group="float"/> + <reg name="f7" bitsize="64" type="float" group="float"/> + <reg name="f8" bitsize="64" type="float" group="float"/> + <reg name="f9" bitsize="64" type="float" group="float"/> + <reg name="f10" bitsize="64" type="float" group="float"/> + <reg name="f11" bitsize="64" type="float" group="float"/> + <reg name="f12" bitsize="64" type="float" group="float"/> + <reg name="f13" bitsize="64" type="float" group="float"/> + <reg name="f14" bitsize="64" type="float" group="float"/> + <reg name="f15" bitsize="64" type="float" group="float"/> + <reg name="f16" bitsize="64" type="float" group="float"/> + <reg name="f17" bitsize="64" type="float" group="float"/> + <reg name="f18" bitsize="64" type="float" group="float"/> + <reg name="f19" bitsize="64" type="float" group="float"/> + <reg name="f20" bitsize="64" type="float" group="float"/> + <reg name="f21" bitsize="64" type="float" group="float"/> + <reg name="f22" bitsize="64" type="float" group="float"/> + <reg name="f23" bitsize="64" type="float" group="float"/> + <reg name="f24" bitsize="64" type="float" group="float"/> + <reg name="f25" bitsize="64" type="float" group="float"/> + <reg name="f26" bitsize="64" type="float" group="float"/> + <reg name="f27" bitsize="64" type="float" group="float"/> + <reg name="f28" bitsize="64" type="float" group="float"/> + <reg name="f29" bitsize="64" type="float" group="float"/> + <reg name="f30" bitsize="64" type="float" group="float"/> + + <!-- Floating-Point Control Register --> + <reg name="fpcr" bitsize="64" type="int64" group="float"/> + + <!-- Program Counter --> + <reg name="pc" bitsize="64" type="code_ptr"/> + + <!-- Reserved Index for Former Virtual Register --> + <reg name="" bitsize="64" type="int64" save-restore="no"/> + + <!-- PALcode Memory Slot --> + <reg name="unique" bitsize="64" type="int64" group="system"/> +</feature> diff --git a/gdb/features/alpha.c b/gdb/features/alpha.c new file mode 100644 index 00000000000..051ded863f1 --- /dev/null +++ b/gdb/features/alpha.c @@ -0,0 +1,84 @@ +/* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: + Original: alpha.xml */ + +#include "osabi.h" +#include "target-descriptions.h" + +const struct target_desc *tdesc_alpha; +static void +initialize_tdesc_alpha (void) +{ + target_desc_up result = allocate_target_description (); + struct tdesc_feature *feature; + + feature = tdesc_create_feature (result.get (), "org.gnu.gdb.alpha.core"); + tdesc_create_reg (feature, "v0", 0, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t0", 1, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t1", 2, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t2", 3, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t3", 4, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t4", 5, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t5", 6, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t6", 7, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t7", 8, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s0", 9, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s1", 10, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s2", 11, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s3", 12, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s4", 13, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "s5", 14, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "fp", 15, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a0", 16, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a1", 17, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a2", 18, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a3", 19, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a4", 20, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "a5", 21, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t8", 22, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t9", 23, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t10", 24, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t11", 25, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "ra", 26, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "t12", 27, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "at", 28, 1, NULL, 64, "int64"); + tdesc_create_reg (feature, "gp", 29, 1, NULL, 64, "data_ptr"); + tdesc_create_reg (feature, "sp", 30, 1, NULL, 64, "data_ptr"); + tdesc_create_reg (feature, "zero", 31, 0, NULL, 64, "int64"); + tdesc_create_reg (feature, "f0", 32, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f1", 33, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f2", 34, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f3", 35, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f4", 36, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f5", 37, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f6", 38, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f7", 39, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f8", 40, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f9", 41, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f10", 42, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f11", 43, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f12", 44, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f13", 45, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f14", 46, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f15", 47, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f16", 48, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f17", 49, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f18", 50, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f19", 51, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f20", 52, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f21", 53, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f22", 54, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f23", 55, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f24", 56, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f25", 57, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f26", 58, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f27", 59, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f28", 60, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f29", 61, 1, "float", 64, "float"); + tdesc_create_reg (feature, "f30", 62, 1, "float", 64, "float"); + tdesc_create_reg (feature, "fpcr", 63, 1, "float", 64, "int64"); + tdesc_create_reg (feature, "pc", 64, 1, NULL, 64, "code_ptr"); + tdesc_create_reg (feature, "", 65, 0, NULL, 64, "int64"); + tdesc_create_reg (feature, "unique", 66, 1, "system", 64, "int64"); + + tdesc_alpha = result.release (); +} diff --git a/gdb/features/alpha.xml b/gdb/features/alpha.xml new file mode 100644 index 00000000000..3ae0ab8b972 --- /dev/null +++ b/gdb/features/alpha.xml @@ -0,0 +1,11 @@ +<?xml version="1.0"?> +<!-- Copyright (C) 2025 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. --> + +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> +<target version="1.0"> + <xi:include href="alpha-core.xml"/> +</target> -- 2.49.0 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar @ 2025-05-26 16:13 ` Eli Zaretskii 2025-05-26 17:14 ` Yodel 2025-06-03 18:49 ` Simon Marchi 2025-07-02 18:48 ` Maciej W. Rozycki 2 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2025-05-26 16:13 UTC (permalink / raw) To: Yodel Eldar; +Cc: gdb-patches > From: Yodel Eldar <yodel.eldar@gmail.com> > Cc: Yodel Eldar <yodel.eldar@gmail.com> > Date: Mon, 26 May 2025 10:12:18 -0500 > > This commit adds target description support for Alpha. > > The target description obviates the alpha_register_type and > alpha_register_name functions in alpha-tdep.c. Removal of > alpha_register_reggroup_p was considered but ultimately abandoned, > because the "info regs" command would no longer omit the zero, fpcr, and > unique registers from its output (they are neither vector nor float > types). > > Register types in the target description annex match the types that the > alpha_register_type function returned. > > The locally defined register_names array was moved out of > alpha_register_name and renamed to alpha_register_names as a static > global; calls to alpha_register_name have been replaced with direct > access of the array. > > The patch follows the code pattern outlined in the following GDB > Internals Wiki entry: > > https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support > --- > gdb/NEWS | 2 + > gdb/alpha-tdep.c | 87 ++++++++++++++++++++---------------- > gdb/doc/gdb.texinfo | 42 ++++++++++++++++++ > gdb/features/Makefile | 1 + > gdb/features/alpha-core.xml | 88 +++++++++++++++++++++++++++++++++++++ > gdb/features/alpha.c | 84 +++++++++++++++++++++++++++++++++++ > gdb/features/alpha.xml | 11 +++++ > 7 files changed, 276 insertions(+), 39 deletions(-) > create mode 100644 gdb/features/alpha-core.xml > create mode 100644 gdb/features/alpha.c > create mode 100644 gdb/features/alpha.xml Thanks. > diff --git a/gdb/NEWS b/gdb/NEWS > index 2e48a00df5a..099c137a16f 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -195,6 +195,8 @@ qXfer:threads:read > subsystem to be disabled at configure time, in the form of > --disable-gdb-compile. > > +* The Alpha target now supports target descriptions. > + > *** Changes in GDB 16 This part is okay. > +The @samp{org.gnu.gdb.alpha.core} feature is required for Alpha targets. It ^^ Two spaces between sentences, please. Reviewed-By: Eli Zaretskii <eliz@gnu.org> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-05-26 16:13 ` Eli Zaretskii @ 2025-05-26 17:14 ` Yodel 0 siblings, 0 replies; 25+ messages in thread From: Yodel @ 2025-05-26 17:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 2484 bytes --] On Mon, May 26, 2025 at 11:13 AM Eli Zaretskii <eliz@gnu.org> wrote: > > From: Yodel Eldar <yodel.eldar@gmail.com> > > Cc: Yodel Eldar <yodel.eldar@gmail.com> > > Date: Mon, 26 May 2025 10:12:18 -0500 > > > > This commit adds target description support for Alpha. > > > > The target description obviates the alpha_register_type and > > alpha_register_name functions in alpha-tdep.c. Removal of > > alpha_register_reggroup_p was considered but ultimately abandoned, > > because the "info regs" command would no longer omit the zero, fpcr, and > > unique registers from its output (they are neither vector nor float > > types). > > > > Register types in the target description annex match the types that the > > alpha_register_type function returned. > > > > The locally defined register_names array was moved out of > > alpha_register_name and renamed to alpha_register_names as a static > > global; calls to alpha_register_name have been replaced with direct > > access of the array. > > > > The patch follows the code pattern outlined in the following GDB > > Internals Wiki entry: > > > > > https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support > > --- > > gdb/NEWS | 2 + > > gdb/alpha-tdep.c | 87 ++++++++++++++++++++---------------- > > gdb/doc/gdb.texinfo | 42 ++++++++++++++++++ > > gdb/features/Makefile | 1 + > > gdb/features/alpha-core.xml | 88 +++++++++++++++++++++++++++++++++++++ > > gdb/features/alpha.c | 84 +++++++++++++++++++++++++++++++++++ > > gdb/features/alpha.xml | 11 +++++ > > 7 files changed, 276 insertions(+), 39 deletions(-) > > create mode 100644 gdb/features/alpha-core.xml > > create mode 100644 gdb/features/alpha.c > > create mode 100644 gdb/features/alpha.xml > > Thanks. > > > diff --git a/gdb/NEWS b/gdb/NEWS > > index 2e48a00df5a..099c137a16f 100644 > > --- a/gdb/NEWS > > +++ b/gdb/NEWS > > @@ -195,6 +195,8 @@ qXfer:threads:read > > subsystem to be disabled at configure time, in the form of > > --disable-gdb-compile. > > > > +* The Alpha target now supports target descriptions. > > + > > *** Changes in GDB 16 > > This part is okay. > > > +The @samp{org.gnu.gdb.alpha.core} feature is required for Alpha > targets. It > > ^^ > Two spaces between sentences, please. > > Thanks for pointing that out. It's corrected now. > Reviewed-By: Eli Zaretskii <eliz@gnu.org> > [-- Attachment #2: Type: text/html, Size: 3719 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar 2025-05-26 16:13 ` Eli Zaretskii @ 2025-06-03 18:49 ` Simon Marchi 2025-06-04 13:44 ` Yodel Eldar 2025-07-02 18:48 ` Maciej W. Rozycki 2 siblings, 1 reply; 25+ messages in thread From: Simon Marchi @ 2025-06-03 18:49 UTC (permalink / raw) To: Yodel Eldar, gdb-patches On 5/26/25 11:12 AM, Yodel Eldar wrote: > @@ -1715,11 +1696,39 @@ alpha_software_single_step (struct regcache *regcache) > static struct gdbarch * > alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) > { > + tdesc_arch_data_up tdesc_data; > + const struct target_desc *tdesc = info.target_desc; > + > /* Find a candidate among extant architectures. */ > arches = gdbarch_list_lookup_by_info (arches, &info); > if (arches != NULL) > return arches->gdbarch; > > + if (tdesc == nullptr) > + tdesc = tdesc_alpha; > + > + /* Validate target description. */ > + if (tdesc_has_registers (tdesc)) > + { > + const struct tdesc_feature *feature; > + bool valid_p; > + > + feature = tdesc_find_feature (tdesc, "org.gnu.gdb.alpha.core"); > + if (feature == nullptr) > + return nullptr; > + > + tdesc_data = tdesc_data_alloc (); > + valid_p = true; > + for (int i = 0; i < ALPHA_NUM_REGS; ++i) > + valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), i, > + alpha_register_names[i]); > + > + if (!valid_p) > + return nullptr; Do we need to call tdesc_numbered_register for the register whose name is ""? I suppose that we do, for backwards compatibility, when debugging against a remote target that doesn't send a target description? Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-03 18:49 ` Simon Marchi @ 2025-06-04 13:44 ` Yodel Eldar 2025-06-04 14:49 ` Maciej W. Rozycki 0 siblings, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-06-04 13:44 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches, Yodel Eldar On 6/3/25 1:49 PM, Simon Marchi wrote: > On 5/26/25 11:12 AM, Yodel Eldar wrote: >> @@ -1715,11 +1696,39 @@ alpha_software_single_step (struct regcache *regcache) >> static struct gdbarch * >> alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) >> { >> + tdesc_arch_data_up tdesc_data; >> + const struct target_desc *tdesc = info.target_desc; >> + >> /* Find a candidate among extant architectures. */ >> arches = gdbarch_list_lookup_by_info (arches, &info); >> if (arches != NULL) >> return arches->gdbarch; >> >> + if (tdesc == nullptr) >> + tdesc = tdesc_alpha; >> + >> + /* Validate target description. */ >> + if (tdesc_has_registers (tdesc)) >> + { >> + const struct tdesc_feature *feature; >> + bool valid_p; >> + >> + feature = tdesc_find_feature (tdesc, "org.gnu.gdb.alpha.core"); >> + if (feature == nullptr) >> + return nullptr; >> + >> + tdesc_data = tdesc_data_alloc (); >> + valid_p = true; >> + for (int i = 0; i < ALPHA_NUM_REGS; ++i) >> + valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), i, >> + alpha_register_names[i]); >> + >> + if (!valid_p) >> + return nullptr; > Do we need to call tdesc_numbered_register for the register whose name > is ""? I suppose that we do, for backwards compatibility, when > debugging against a remote target that doesn't send a target > description? > > Simon Hi Simon and thanks for your time and question! I think we do, because (IIUC) suppose an older remote target responds to, say, a 'p n' packet, but the anonymous register is unaccounted for by the client, wouldn't that break compatibility? Can't say for certain, so I defer to your and the community's wisdom and err on the side of caution as I investigate it. Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-04 13:44 ` Yodel Eldar @ 2025-06-04 14:49 ` Maciej W. Rozycki 2025-06-04 17:29 ` Yodel Eldar 0 siblings, 1 reply; 25+ messages in thread From: Maciej W. Rozycki @ 2025-06-04 14:49 UTC (permalink / raw) To: Yodel Eldar; +Cc: Simon Marchi, gdb-patches On Wed, 4 Jun 2025, Yodel Eldar wrote: > > Do we need to call tdesc_numbered_register for the register whose name > > is ""? I suppose that we do, for backwards compatibility, when > > debugging against a remote target that doesn't send a target > > description? > > Hi Simon and thanks for your time and question! I think we do, because > (IIUC) suppose an older remote target responds to, say, a 'p n' packet, > but the anonymous register is unaccounted for by the client, wouldn't > that break compatibility? Can't say for certain, so I defer to your and > the community's wisdom and err on the side of caution as I investigate > it. Are there any remote Alpha targets there in the first place? I only have writing Alpha/Linux gdbserver on my todo list once I'm done with the more urgent Alpha stuff (Linux kernel EV4 support restoration, GCC LRA conversion) and I haven't heard of any other Alpha GDB RSP debug stub either. There *might* be something in QEMU; I guess that'd be the only place to check. Maciej ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-04 14:49 ` Maciej W. Rozycki @ 2025-06-04 17:29 ` Yodel Eldar 2025-06-12 19:29 ` Yodel Eldar 0 siblings, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-06-04 17:29 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Simon Marchi, gdb-patches, Yodel Eldar On 6/4/25 9:49 AM, Maciej W. Rozycki wrote: > On Wed, 4 Jun 2025, Yodel Eldar wrote: > >>> Do we need to call tdesc_numbered_register for the register whose name >>> is ""? I suppose that we do, for backwards compatibility, when >>> debugging against a remote target that doesn't send a target >>> description? >> Hi Simon and thanks for your time and question! I think we do, because >> (IIUC) suppose an older remote target responds to, say, a 'p n' packet, >> but the anonymous register is unaccounted for by the client, wouldn't >> that break compatibility? Can't say for certain, so I defer to your and >> the community's wisdom and err on the side of caution as I investigate >> it. > Are there any remote Alpha targets there in the first place? > > I only have writing Alpha/Linux gdbserver on my todo list once I'm done > with the more urgent Alpha stuff (Linux kernel EV4 support restoration, > GCC LRA conversion) and I haven't heard of any other Alpha GDB RSP debug > stub either. There *might* be something in QEMU; I guess that'd be the > only place to check. > > Maciej > Maciej, you hit the nail on the head! Indeed, QEMU is the project I alluded to in the cover letter for the patch, and I have been using it for testing throughout the development of the patch. It also provided the impetus to write the target description for Alpha in the first place as it uses them for its execlog plugin. Thanks for taking the time to reply despite having more pressing Alpha tasks. I will keep an eye out for your forthcoming submissions, and provide my modest feedback if it's helpful. Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-04 17:29 ` Yodel Eldar @ 2025-06-12 19:29 ` Yodel Eldar 2025-06-12 20:30 ` Simon Marchi 0 siblings, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-06-12 19:29 UTC (permalink / raw) To: Simon Marchi; +Cc: Maciej W. Rozycki, Yodel Eldar, gdb-patches On 6/4/25 12:29 PM, Yodel Eldar wrote: > > On 6/4/25 9:49 AM, Maciej W. Rozycki wrote: >> On Wed, 4 Jun 2025, Yodel Eldar wrote: >> >>>> Do we need to call tdesc_numbered_register for the register whose name >>>> is ""? I suppose that we do, for backwards compatibility, when >>>> debugging against a remote target that doesn't send a target >>>> description? >>> Hi Simon and thanks for your time and question! I think we do, because >>> (IIUC) suppose an older remote target responds to, say, a 'p n' packet, >>> but the anonymous register is unaccounted for by the client, wouldn't >>> that break compatibility? Can't say for certain, so I defer to your and >>> the community's wisdom and err on the side of caution as I investigate >>> it. >> Are there any remote Alpha targets there in the first place? >> >> I only have writing Alpha/Linux gdbserver on my todo list once I'm >> done >> with the more urgent Alpha stuff (Linux kernel EV4 support restoration, >> GCC LRA conversion) and I haven't heard of any other Alpha GDB RSP debug >> stub either. There *might* be something in QEMU; I guess that'd be the >> only place to check. >> >> Maciej >> > > Maciej, you hit the nail on the head! Indeed, QEMU is the project I > alluded to in the cover letter for the patch, and I have been using it > for testing throughout the development of the patch. It also provided > the impetus to write the target description for Alpha in the first > place as it uses them for its execlog plugin. > Thanks for taking the time to reply despite having more pressing > Alpha tasks. I will keep an eye out for your forthcoming submissions, > and provide my modest feedback if it's helpful. > > Yodel > Hi Simon et al! Update regarding the feasibility of skipping the tdesc_numbered_register (TNR) call on the anonymous register: I modified the patch to skip the TNR call (see below for diff), and ran the "maintenance print remote-registers" command while connected to a QEMU Alpha remote with "set debug remote on" and observed the following (see below for the abridged command output): 1. GDB internally creates a 0-bit wide placeholder at the anonymous register's expected index (65), and that placeholder shares the GDB internal offset of the unique register (520). 2. GDB infers the anonymous register as its 67th register with internal offset 528 and type int64_t. 3. Despite having an internal number of 67, GDB does assign the anonymous register the correct remote number of 65 and the correct g/G offset of 520. 4. 'g' and 'p n' packets (particularly, where n is unique's remote number 66) do not appear to corrupt the regcache as I had feared. On the one hand, observations 3 and 4 suggest that skipping TNR on the anonymous register could work, but the discrepancy between the internal versus g/G offsets and the internal versus remote numbers (observations 1 and 2) makes me wary of some hard-to-find side-effect that I may have yet overlooked. Furthermore, 67 is the number of total registers, so assigning 67 for the anonymous register's internal number (observation 3) could be problematic. Moreover, having GDB implicitly account for the anonymous register at 67 while also displaying a 0-bit register placeholder at 65 seems gratuitous and probably offsets any performance benefit derived from skipping TNR on the anonymous register. With regard to backwards compatibility, I compiled a 2011 version of QEMU, commit b758aca1f6c, and performed the same experiment as above, and the output of the maintenance command was identical to the recent version used earlier. Likewise for the 2008 commit 19bf517b7f7 that introduced GDB stub support for QEMU's Alpha target, although this version had not implemented PALcode functionality and lacked the unique register. Fortunately, all three did not appear to have problems communicating with the GDB client, notwithstanding my concerns, but the scope of my testing was limited to the QEMU targets, and I don't think it qualifies as a comprehensive answer to the compatibility question as my inability to find other targets does not preclude their existence. Thus, I recommend against the omission of tdesc_numbered_register on the anonymous register. Please let me know how to proceed; should v2 of the patch omit the tdesc_numbered_register call on the anonymous register? I defer to your judgment. Thanks! Yodel ------------------------ Diff of changes to patch ------------------------ diff --git a/gdb/alpha-tdep.c b/gdb/alpha-tdep.c index 60888a6f475..262a578b39c 100644 --- a/gdb/alpha-tdep.c +++ b/gdb/alpha-tdep.c @@ -1719,10 +1719,13 @@ alpha_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) tdesc_data = tdesc_data_alloc (); valid_p = true; - for (int i = 0; i < ALPHA_NUM_REGS; ++i) + for (int i = 0; i <= ALPHA_PC_REGNUM; ++i) valid_p &= tdesc_numbered_register (feature, tdesc_data.get (), i, alpha_register_names[i]); + valid_p &= tdesc_numbered_register(feature, tdesc_data.get (), + ALPHA_UNIQUE_REGNUM, + alpha_register_names[ALPHA_UNIQUE_REGNUM]); if (!valid_p) return nullptr; } ------------------------------------------------------- Remote registers with omitted TNR on anonymous register ------------------------------------------------------- (gdb) maintenance print remote-registers Name Nr Rel Offset Size Type Rmt Nr g/G Offset Expedited v0 0 0 0 8 int64_t 0 0 t0 1 1 8 8 int64_t 1 8 ... pc 64 64 512 8 *1 64 512 '' 65 65 520 0 int0_t unique 66 66 520 8 int64_t 66 528 '' 67 67 528 8 int64_t 65 520 *1: Register type's name NULL. ----------------------------------------------- Remote registers with TNR on anonymous register ----------------------------------------------- (gdb) maintenance print remote-registers Name Nr Rel Offset Size Type Rmt Nr g/G Offset Expedited v0 0 0 0 8 int64_t 0 0 t0 1 1 8 8 int64_t 1 8 ... pc 64 64 512 8 *1 64 512 '' 65 65 520 8 int64_t 65 520 unique 66 66 528 8 int64_t 66 528 *1: Register type's name NULL. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-12 19:29 ` Yodel Eldar @ 2025-06-12 20:30 ` Simon Marchi 2025-06-12 20:33 ` Simon Marchi 2025-07-02 18:53 ` Maciej W. Rozycki 0 siblings, 2 replies; 25+ messages in thread From: Simon Marchi @ 2025-06-12 20:30 UTC (permalink / raw) To: Yodel Eldar; +Cc: Maciej W. Rozycki, gdb-patches On 2025-06-12 15:29, Yodel Eldar wrote: > > On 6/4/25 12:29 PM, Yodel Eldar wrote: >> >> On 6/4/25 9:49 AM, Maciej W. Rozycki wrote: >>> On Wed, 4 Jun 2025, Yodel Eldar wrote: >>> >>>>> Do we need to call tdesc_numbered_register for the register whose name >>>>> is ""? I suppose that we do, for backwards compatibility, when >>>>> debugging against a remote target that doesn't send a target >>>>> description? >>>> Hi Simon and thanks for your time and question! I think we do, because >>>> (IIUC) suppose an older remote target responds to, say, a 'p n' packet, >>>> but the anonymous register is unaccounted for by the client, wouldn't >>>> that break compatibility? Can't say for certain, so I defer to your and >>>> the community's wisdom and err on the side of caution as I investigate >>>> it. >>> Are there any remote Alpha targets there in the first place? >>> >>> I only have writing Alpha/Linux gdbserver on my todo list once I'm done >>> with the more urgent Alpha stuff (Linux kernel EV4 support restoration, >>> GCC LRA conversion) and I haven't heard of any other Alpha GDB RSP debug >>> stub either. There *might* be something in QEMU; I guess that'd be the >>> only place to check. >>> >>> Maciej >>> >> >> Maciej, you hit the nail on the head! Indeed, QEMU is the project I >> alluded to in the cover letter for the patch, and I have been using it >> for testing throughout the development of the patch. It also provided >> the impetus to write the target description for Alpha in the first >> place as it uses them for its execlog plugin. >> Thanks for taking the time to reply despite having more pressing >> Alpha tasks. I will keep an eye out for your forthcoming submissions, >> and provide my modest feedback if it's helpful. >> >> Yodel >> > > Hi Simon et al! > > Update regarding the feasibility of skipping the tdesc_numbered_register > (TNR) call on the anonymous register: > > I modified the patch to skip the TNR call (see below for diff), and ran > the "maintenance print remote-registers" command while connected to a > QEMU Alpha remote with "set debug remote on" and observed the following > (see below for the abridged command output): > 1. GDB internally creates a 0-bit wide placeholder at the anonymous > register's expected index (65), and that placeholder shares the GDB > internal offset of the unique register (520). > 2. GDB infers the anonymous register as its 67th register with > internal offset 528 and type int64_t. > 3. Despite having an internal number of 67, GDB does assign the > anonymous register the correct remote number of 65 and the correct > g/G offset of 520. > 4. 'g' and 'p n' packets (particularly, where n is unique's remote > number 66) do not appear to corrupt the regcache as I had feared. > > On the one hand, observations 3 and 4 suggest that skipping TNR on the > anonymous register could work, but the discrepancy between the internal > versus g/G offsets and the internal versus remote numbers (observations > 1 and 2) makes me wary of some hard-to-find side-effect that I may have > yet overlooked. Furthermore, 67 is the number of total registers, so > assigning 67 for the anonymous register's internal number (observation > 3) could be problematic. > > Moreover, having GDB implicitly account for the anonymous register at 67 > while also displaying a 0-bit register placeholder at 65 seems > gratuitous and probably offsets any performance benefit derived from > skipping TNR on the anonymous register. > > With regard to backwards compatibility, I compiled a 2011 version of > QEMU, commit b758aca1f6c, and performed the same experiment as above, > and the output of the maintenance command was identical to the recent > version used earlier. Likewise for the 2008 commit 19bf517b7f7 that > introduced GDB stub support for QEMU's Alpha target, although this > version had not implemented PALcode functionality and lacked the unique > register. Fortunately, all three did not appear to have problems > communicating with the GDB client, notwithstanding my concerns, but the > scope of my testing was limited to the QEMU targets, and I don't think > it qualifies as a comprehensive answer to the compatibility question as > my inability to find other targets does not preclude their existence. > > Thus, I recommend against the omission of tdesc_numbered_register on the > anonymous register. > > Please let me know how to proceed; should v2 of the patch omit the > tdesc_numbered_register call on the anonymous register? I defer to your > judgment. Thanks! Thanks for the detailed investigation. I'm not super familiar with register descriptions and the register numbering. I think it's better to be on the safe side and leave it there, it shouldn't bother anybody. From my non-Alpha-expert point of view, the series LGTM, so I'm tempted to approve it. Maciej, did you have some comments on the code? Does it look good to you? Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-12 20:30 ` Simon Marchi @ 2025-06-12 20:33 ` Simon Marchi 2025-06-12 22:07 ` Yodel Eldar 2025-07-02 18:53 ` Maciej W. Rozycki 1 sibling, 1 reply; 25+ messages in thread From: Simon Marchi @ 2025-06-12 20:33 UTC (permalink / raw) To: Yodel Eldar; +Cc: Maciej W. Rozycki, gdb-patches On 2025-06-12 16:30, Simon Marchi wrote: > Thanks for the detailed investigation. I'm not super familiar with > register descriptions and the register numbering. I think it's better > to be on the safe side and leave it there, it shouldn't bother anybody. > > From my non-Alpha-expert point of view, the series LGTM, so I'm tempted > to approve it. Maciej, did you have some comments on the code? Does it > look good to you? However, do you have a copyright assignment on file with the FSF? This is required in order to contribute any non-trivial code. If not, please see: https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-12 20:33 ` Simon Marchi @ 2025-06-12 22:07 ` Yodel Eldar 2025-06-13 14:34 ` Simon Marchi 0 siblings, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-06-12 22:07 UTC (permalink / raw) To: Simon Marchi; +Cc: Maciej W. Rozycki, Yodel Eldar, gdb-patches On 6/12/25 3:33 PM, Simon Marchi wrote: > > On 2025-06-12 16:30, Simon Marchi wrote: >> Thanks for the detailed investigation. I'm not super familiar with >> register descriptions and the register numbering. I think it's better >> to be on the safe side and leave it there, it shouldn't bother anybody. >> >> From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >> to approve it. Maciej, did you have some comments on the code? Does it >> look good to you? > However, do you have a copyright assignment on file with the FSF? This > is required in order to contribute any non-trivial code. If not, please > see: > > https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD > > Simon Thanks for the swift response! I don't have an assignment on file, but I just submitted the request form and await their response. Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-12 22:07 ` Yodel Eldar @ 2025-06-13 14:34 ` Simon Marchi 2025-06-30 0:08 ` Yodel Eldar 0 siblings, 1 reply; 25+ messages in thread From: Simon Marchi @ 2025-06-13 14:34 UTC (permalink / raw) To: Yodel Eldar; +Cc: Maciej W. Rozycki, gdb-patches On 6/12/25 6:07 PM, Yodel Eldar wrote: > > On 6/12/25 3:33 PM, Simon Marchi wrote: >> >> On 2025-06-12 16:30, Simon Marchi wrote: >>> Thanks for the detailed investigation. I'm not super familiar with >>> register descriptions and the register numbering. I think it's better >>> to be on the safe side and leave it there, it shouldn't bother anybody. >>> >>> From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>> to approve it. Maciej, did you have some comments on the code? Does it >>> look good to you? >> However, do you have a copyright assignment on file with the FSF? This >> is required in order to contribute any non-trivial code. If not, please >> see: >> >> https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD >> >> Simon > > > Thanks for the swift response! > > I don't have an assignment on file, but I just submitted the request > form and await their response. Thanks, let us know when it's done. Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-13 14:34 ` Simon Marchi @ 2025-06-30 0:08 ` Yodel Eldar 2025-07-02 17:14 ` Simon Marchi 0 siblings, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-06-30 0:08 UTC (permalink / raw) To: Simon Marchi; +Cc: Maciej W. Rozycki, gdb-patches, Yodel Eldar On 6/13/25 9:34 AM, Simon Marchi wrote: > On 6/12/25 6:07 PM, Yodel Eldar wrote: >> On 6/12/25 3:33 PM, Simon Marchi wrote: >>> On 2025-06-12 16:30, Simon Marchi wrote: >>>> Thanks for the detailed investigation. I'm not super familiar with >>>> register descriptions and the register numbering. I think it's better >>>> to be on the safe side and leave it there, it shouldn't bother anybody. >>>> >>>> From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>>> to approve it. Maciej, did you have some comments on the code? Does it >>>> look good to you? >>> However, do you have a copyright assignment on file with the FSF? This >>> is required in order to contribute any non-trivial code. If not, please >>> see: >>> >>> https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD >>> >>> Simon >> >> Thanks for the swift response! >> >> I don't have an assignment on file, but I just submitted the request >> form and await their response. > Thanks, let us know when it's done. > > Simon Happy to report that the assignment process with the FSF is now complete! Please let me know how to proceed. Should I resubmit the series with the fix of the formatting error that Eli Zaretskii noticed in the first patch? Thanks, Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-30 0:08 ` Yodel Eldar @ 2025-07-02 17:14 ` Simon Marchi 2025-07-02 18:51 ` Yodel Eldar 0 siblings, 1 reply; 25+ messages in thread From: Simon Marchi @ 2025-07-02 17:14 UTC (permalink / raw) To: Yodel Eldar; +Cc: Maciej W. Rozycki, gdb-patches On 6/29/25 8:08 PM, Yodel Eldar wrote: > > On 6/13/25 9:34 AM, Simon Marchi wrote: >> On 6/12/25 6:07 PM, Yodel Eldar wrote: >>> On 6/12/25 3:33 PM, Simon Marchi wrote: >>>> On 2025-06-12 16:30, Simon Marchi wrote: >>>>> Thanks for the detailed investigation. I'm not super familiar with >>>>> register descriptions and the register numbering. I think it's better >>>>> to be on the safe side and leave it there, it shouldn't bother anybody. >>>>> >>>>> From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>>>> to approve it. Maciej, did you have some comments on the code? Does it >>>>> look good to you? >>>> However, do you have a copyright assignment on file with the FSF? This >>>> is required in order to contribute any non-trivial code. If not, please >>>> see: >>>> >>>> https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD >>>> >>>> Simon >>> >>> Thanks for the swift response! >>> >>> I don't have an assignment on file, but I just submitted the request >>> form and await their response. >> Thanks, let us know when it's done. >> >> Simon > > > Happy to report that the assignment process with the FSF is now > complete! > > Please let me know how to proceed. > > Should I resubmit the series with the fix of the formatting error that > Eli Zaretskii noticed in the first patch? Thanks, I see the entry for you assignment. I will push the patch on your behalf with that fixed. If you plan to contribute regularly, you can ask for write access to the repo. Let me know if you want to do that. Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 17:14 ` Simon Marchi @ 2025-07-02 18:51 ` Yodel Eldar 0 siblings, 0 replies; 25+ messages in thread From: Yodel Eldar @ 2025-07-02 18:51 UTC (permalink / raw) To: Simon Marchi; +Cc: Maciej W. Rozycki, gdb-patches, eliz, Yodel Eldar [-- Attachment #1.1.1: Type: text/plain, Size: 2282 bytes --] On 7/2/25 12:14 PM, Simon Marchi wrote: > On 6/29/25 8:08 PM, Yodel Eldar wrote: >> On 6/13/25 9:34 AM, Simon Marchi wrote: >>> On 6/12/25 6:07 PM, Yodel Eldar wrote: >>>> On 6/12/25 3:33 PM, Simon Marchi wrote: >>>>> On 2025-06-12 16:30, Simon Marchi wrote: >>>>>> Thanks for the detailed investigation. I'm not super familiar with >>>>>> register descriptions and the register numbering. I think it's better >>>>>> to be on the safe side and leave it there, it shouldn't bother anybody. >>>>>> >>>>>> From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>>>>> to approve it. Maciej, did you have some comments on the code? Does it >>>>>> look good to you? >>>>> However, do you have a copyright assignment on file with the FSF? This >>>>> is required in order to contribute any non-trivial code. If not, please >>>>> see: >>>>> >>>>> https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/Copyright/request-assign.future;hb=HEAD >>>>> >>>>> Simon >>>> Thanks for the swift response! >>>> >>>> I don't have an assignment on file, but I just submitted the request >>>> form and await their response. >>> Thanks, let us know when it's done. >>> >>> Simon >> >> Happy to report that the assignment process with the FSF is now >> complete! >> >> Please let me know how to proceed. >> >> Should I resubmit the series with the fix of the formatting error that >> Eli Zaretskii noticed in the first patch? > Thanks, I see the entry for you assignment. > > I will push the patch on your behalf with that fixed. If you plan to > contribute regularly, you can ask for write access to the repo. Let me > know if you want to do that. > > Simon Excellent! Thanks for all of your help, Simon! I also want to thank Eli for his review and Maciej for taking the time. I won't ask for write access this time, but for future contributions (and as they become regular) it would be nice to be able to sign the commit with my GPG key, so I'll ask for it then. For now and posterity, I'll digitally sign this email. Also, my nick on Libera.Chat is "yodel", and I'm in the #gdb channel; please contact me by either email or IRC if there's anything I can do to help the project. Thanks, Yodel [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 703 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-06-12 20:30 ` Simon Marchi 2025-06-12 20:33 ` Simon Marchi @ 2025-07-02 18:53 ` Maciej W. Rozycki 2025-07-02 19:02 ` Simon Marchi 1 sibling, 1 reply; 25+ messages in thread From: Maciej W. Rozycki @ 2025-07-02 18:53 UTC (permalink / raw) To: Simon Marchi; +Cc: Yodel Eldar, gdb-patches On Thu, 12 Jun 2025, Simon Marchi wrote: > >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted > to approve it. Maciej, did you have some comments on the code? Does it > look good to you? I've skimmed over now and found one minor formatting nit only, which I do hope you can address as you push this change. Otherwise if there turns out indeed anything wrong with the code later on, it can be dealt with as required. I'm not prepared right now for any further verification of this target. Maciej ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 18:53 ` Maciej W. Rozycki @ 2025-07-02 19:02 ` Simon Marchi 2025-07-02 19:21 ` Maciej W. Rozycki 0 siblings, 1 reply; 25+ messages in thread From: Simon Marchi @ 2025-07-02 19:02 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Yodel Eldar, gdb-patches On 7/2/25 2:53 PM, Maciej W. Rozycki wrote: > On Thu, 12 Jun 2025, Simon Marchi wrote: > >> >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >> to approve it. Maciej, did you have some comments on the code? Does it >> look good to you? > > I've skimmed over now and found one minor formatting nit only, which I do > hope you can address as you push this change. Otherwise if there turns > out indeed anything wrong with the code later on, it can be dealt with as > required. I'm not prepared right now for any further verification of this > target. I didn't fix any formatting problem other than the one pointed out by Eli. What did you find? Or else, feel free to fix it by yourself with an obvious patch. Thanks, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 19:02 ` Simon Marchi @ 2025-07-02 19:21 ` Maciej W. Rozycki 2025-07-02 20:52 ` Yodel Eldar 2025-07-03 16:02 ` Simon Marchi 0 siblings, 2 replies; 25+ messages in thread From: Maciej W. Rozycki @ 2025-07-02 19:21 UTC (permalink / raw) To: Simon Marchi; +Cc: Yodel Eldar, gdb-patches On Wed, 2 Jul 2025, Simon Marchi wrote: > >> >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted > >> to approve it. Maciej, did you have some comments on the code? Does it > >> look good to you? > > > > I've skimmed over now and found one minor formatting nit only, which I do > > hope you can address as you push this change. Otherwise if there turns > > out indeed anything wrong with the code later on, it can be dealt with as > > required. I'm not prepared right now for any further verification of this > > target. > > I didn't fix any formatting problem other than the one pointed out by > Eli. What did you find? Or else, feel free to fix it by yourself with > an obvious patch. Just a place asking for a new line for legibility reasons. If you've already pushed the change, then I can apply a follow-up update myself. Maciej ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 19:21 ` Maciej W. Rozycki @ 2025-07-02 20:52 ` Yodel Eldar 2025-07-02 21:12 ` Maciej W. Rozycki 2025-07-03 16:02 ` Simon Marchi 1 sibling, 1 reply; 25+ messages in thread From: Yodel Eldar @ 2025-07-02 20:52 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: gdb-patches, Simon Marchi, Yodel Eldar On 7/2/25 2:21 PM, Maciej W. Rozycki wrote: > On Wed, 2 Jul 2025, Simon Marchi wrote: > >>>> >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>>> to approve it. Maciej, did you have some comments on the code? Does it >>>> look good to you? >>> I've skimmed over now and found one minor formatting nit only, which I do >>> hope you can address as you push this change. Otherwise if there turns >>> out indeed anything wrong with the code later on, it can be dealt with as >>> required. I'm not prepared right now for any further verification of this >>> target. >> I didn't fix any formatting problem other than the one pointed out by >> Eli. What did you find? Or else, feel free to fix it by yourself with >> an obvious patch. > Just a place asking for a new line for legibility reasons. If you've > already pushed the change, then I can apply a follow-up update myself. > > Maciej Hi, Maciej! For unknown reasons, your emails are not appearing in my inbox (or even the Spam folder) on any of the email clients I use. Fortunately, I'm able to import them from the gdb-patches public inbox, but I had not seen your email about the newline until after I sent my previous email. I agree, there should be a newline between the new addition and the existing comment. Thanks for noticing and the follow-up update. Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 20:52 ` Yodel Eldar @ 2025-07-02 21:12 ` Maciej W. Rozycki 2025-07-03 16:49 ` Yodel Eldar 0 siblings, 1 reply; 25+ messages in thread From: Maciej W. Rozycki @ 2025-07-02 21:12 UTC (permalink / raw) To: Yodel Eldar; +Cc: gdb-patches, Simon Marchi On Wed, 2 Jul 2025, Yodel Eldar wrote: > Hi, Maciej! For unknown reasons, your emails are not appearing in my > inbox (or even the Spam folder) on any of the email clients I use. > Fortunately, I'm able to import them from the gdb-patches public inbox, > but I had not seen your email about the newline until after I sent my > previous email. Indeed a while ago GMail started refusing e-mail originating from my mail server owing to the lack of annotation they require. You'll still receive copies via the mailing list as long as you're subscribed, which I take it you're not. Apologies for the inconvenience, but I'm not going to do anything about it. E-mail is analogous to post and just as anyone can post anything through my letter box I expect all recipients to accept all the e-mail I send and not just messages specially marked on the envelope. Just as it has been through 30 years I've been using this way to communicate. Maciej ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 21:12 ` Maciej W. Rozycki @ 2025-07-03 16:49 ` Yodel Eldar 0 siblings, 0 replies; 25+ messages in thread From: Yodel Eldar @ 2025-07-03 16:49 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: gdb-patches, Simon Marchi, Yodel Eldar On 7/2/25 4:12 PM, Maciej W. Rozycki wrote: > On Wed, 2 Jul 2025, Yodel Eldar wrote: > >> Hi, Maciej! For unknown reasons, your emails are not appearing in my >> inbox (or even the Spam folder) on any of the email clients I use. >> Fortunately, I'm able to import them from the gdb-patches public inbox, >> but I had not seen your email about the newline until after I sent my >> previous email. > Indeed a while ago GMail started refusing e-mail originating from my mail > server owing to the lack of annotation they require. You'll still receive > copies via the mailing list as long as you're subscribed, which I take it > you're not. > > Apologies for the inconvenience, but I'm not going to do anything about > it. E-mail is analogous to post and just as anyone can post anything > through my letter box I expect all recipients to accept all the e-mail I > send and not just messages specially marked on the envelope. Just as it > has been through 30 years I've been using this way to communicate. > > Maciej On a second reading of my previous email, it does look like I was complaining about having to import from the public inbox, but that was not my intention; I meant to clarify how I was able to respond despite not having a copy of your emails in my inbox. I loathe the thought of having elicited an apology from a veteran developer such as yourself for whom I have immense respect and gratitude as there is nothing that calls for an apology in my view, and I certainly would neither ask nor expect you to modify your server/DNS configuration to accommodate for my or GMail's security preferences/requirements. I have been experimenting with different configurations of the public email based patch workflow in the following order: 1. Individual delivery subscription 2. NNTP 3. Digest subscription 4. Atom Feed (current setup) Next will probably be a dedicated, self-managed email server where I will be able to whitelist email addresses/domains at will. Thanks for sharing your perspective on how emails should operate, especially in the context of a public email based workflow; it will help me fine-tune my server configuration in the near future. Yodel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-07-02 19:21 ` Maciej W. Rozycki 2025-07-02 20:52 ` Yodel Eldar @ 2025-07-03 16:02 ` Simon Marchi 1 sibling, 0 replies; 25+ messages in thread From: Simon Marchi @ 2025-07-03 16:02 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Yodel Eldar, gdb-patches On 2025-07-02 15:21, Maciej W. Rozycki wrote: > On Wed, 2 Jul 2025, Simon Marchi wrote: > >>>> >From my non-Alpha-expert point of view, the series LGTM, so I'm tempted >>>> to approve it. Maciej, did you have some comments on the code? Does it >>>> look good to you? >>> >>> I've skimmed over now and found one minor formatting nit only, which I do >>> hope you can address as you push this change. Otherwise if there turns >>> out indeed anything wrong with the code later on, it can be dealt with as >>> required. I'm not prepared right now for any further verification of this >>> target. >> >> I didn't fix any formatting problem other than the one pointed out by >> Eli. What did you find? Or else, feel free to fix it by yourself with >> an obvious patch. > > Just a place asking for a new line for legibility reasons. If you've > already pushed the change, then I can apply a follow-up update myself. > > Maciej Ah ok, I missed that message. I just pushed this: From 01d8dc11f18d774bc92b0b752e36510f86c6725c Mon Sep 17 00:00:00 2001 From: Simon Marchi <simon.marchi@polymtl.ca> Date: Thu, 3 Jul 2025 12:00:49 -0400 Subject: [PATCH] gdb/alpha-tdep: add empty line This was suggested in review, to separate the comment from the following code. Change-Id: I077ad4545ee5ef1d362dcfacf585400e26dfdb29 --- gdb/alpha-tdep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gdb/alpha-tdep.c b/gdb/alpha-tdep.c index 5e8a7a02c2fa..d655c13b8293 100644 --- a/gdb/alpha-tdep.c +++ b/gdb/alpha-tdep.c @@ -1829,6 +1829,7 @@ INIT_GDB_FILE (alpha_tdep) gdbarch_register (bfd_arch_alpha, alpha_gdbarch_init, NULL); initialize_tdesc_alpha (); + /* Let the user set the fence post for heuristic_proc_start. */ /* We really would like to have both "0" and "unlimited" work, but base-commit: 239f72374aab88a5b16855c01e75ed2c5b10960f -- 2.50.0 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/2] gdb/alpha: Add target description support 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar 2025-05-26 16:13 ` Eli Zaretskii 2025-06-03 18:49 ` Simon Marchi @ 2025-07-02 18:48 ` Maciej W. Rozycki 2 siblings, 0 replies; 25+ messages in thread From: Maciej W. Rozycki @ 2025-07-02 18:48 UTC (permalink / raw) To: Yodel Eldar; +Cc: gdb-patches On Mon, 26 May 2025, Yodel Eldar wrote: > diff --git a/gdb/alpha-tdep.c b/gdb/alpha-tdep.c > index f0272b0e49d..60888a6f475 100644 > --- a/gdb/alpha-tdep.c > +++ b/gdb/alpha-tdep.c > @@ -1822,6 +1830,7 @@ _initialize_alpha_tdep () > > gdbarch_register (bfd_arch_alpha, alpha_gdbarch_init, NULL); > > + initialize_tdesc_alpha (); > /* Let the user set the fence post for heuristic_proc_start. */ > > /* We really would like to have both "0" and "unlimited" work, but I think there should be a new line between the new addition and the comment below. This is the only minor nit I have about this change. Maciej ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 2/2] gdb/alpha: Redefine fpcr with fpcr_flags type 2025-05-26 15:12 [PATCH 0/2] gdb/alpha: Add target description support and fpcr flags Yodel Eldar 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar @ 2025-05-26 15:12 ` Yodel Eldar 1 sibling, 0 replies; 25+ messages in thread From: Yodel Eldar @ 2025-05-26 15:12 UTC (permalink / raw) To: gdb-patches; +Cc: Yodel Eldar This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr. For details on the floating-point control register (fpcr), please see the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it consists of a 64-bit bitfield with most bits reserved/unused. All but a pair of the used bits are boolean flags; the exception, DYN_RM, is a 2-bit enum indicating the IEEE rounding mode and is defined as a dyn_rm_enum type in the target description annex. [1] https://archive.org/details/dec-alpha_arch_ref --- gdb/features/alpha-core.xml | 50 ++++++++++++++++++++++++++++++++++++- gdb/features/alpha.c | 29 ++++++++++++++++++++- 2 files changed, 77 insertions(+), 2 deletions(-) diff --git a/gdb/features/alpha-core.xml b/gdb/features/alpha-core.xml index 9b4d71cf855..c9e12f4ffdd 100644 --- a/gdb/features/alpha-core.xml +++ b/gdb/features/alpha-core.xml @@ -7,6 +7,54 @@ <!DOCTYPE feature SYSTEM "gdb-target.dtd"> <feature name="org.gnu.gdb.alpha.core"> + <!-- IEEE rounding mode values --> + <enum id="dyn_rm_enum" size="8"> + <!-- Chopped rounding mode --> + <evalue name="chop" value="0"/> + <!-- Minus infinity --> + <evalue name="-inf" value="1"/> + <!-- Normal rounding --> + <evalue name="norm" value="2"/> + <!-- Plus infinity --> + <evalue name="+inf" value="3"/> + </enum> + + <!-- Floating-Point Control Register Flags --> + <flags id="fpcr_flags" size="8"> + <!-- Denormal Operand Exception Disable --> + <field name="DNOD" start="47" end="47"/> + <!-- Denormal Operands to Zero --> + <field name="DNZ" start="48" end="48"/> + <!-- Invalid Operation Disable --> + <field name="INVD" start="49" end="49"/> + <!-- Division by Zero Disable --> + <field name="DZED" start="50" end="50"/> + <!-- Overflow Disable --> + <field name="OVFD" start="51" end="51"/> + <!-- Invalid Operation --> + <field name="INV" start="52" end="52"/> + <!-- Division by Zero --> + <field name="DZE" start="53" end="53"/> + <!-- Overflow --> + <field name="OVF" start="54" end="54"/> + <!-- Underflow --> + <field name="UNF" start="55" end="55"/> + <!-- Inexact Result --> + <field name="INE" start="56" end="56"/> + <!-- Integer Overflow --> + <field name="IOV" start="57" end="57"/> + <!-- Dynamic Rounding Mode --> + <field name="DYN_RM" start="58" end="59" type="dyn_rm_enum"/> + <!-- Underflow to Zero --> + <field name="UNDZ" start="60" end="60"/> + <!-- Underflow Disable --> + <field name="UNFD" start="61" end="61"/> + <!-- Inexact Disable --> + <field name="INED" start="62" end="62"/> + <!-- Summary Bit --> + <field name="SUM" start="63" end="63"/> + </flags> + <!-- Integer Registers --> <reg name="v0" bitsize="64" type="int64"/> <reg name="t0" bitsize="64" type="int64"/> @@ -75,7 +123,7 @@ <reg name="f30" bitsize="64" type="float" group="float"/> <!-- Floating-Point Control Register --> - <reg name="fpcr" bitsize="64" type="int64" group="float"/> + <reg name="fpcr" bitsize="64" type="fpcr_flags" group="float"/> <!-- Program Counter --> <reg name="pc" bitsize="64" type="code_ptr"/> diff --git a/gdb/features/alpha.c b/gdb/features/alpha.c index 051ded863f1..35f12fcbd4c 100644 --- a/gdb/features/alpha.c +++ b/gdb/features/alpha.c @@ -12,6 +12,33 @@ initialize_tdesc_alpha (void) struct tdesc_feature *feature; feature = tdesc_create_feature (result.get (), "org.gnu.gdb.alpha.core"); + tdesc_type_with_fields *type_with_fields; + type_with_fields = tdesc_create_enum (feature, "dyn_rm_enum", 8); + tdesc_add_enum_value (type_with_fields, 0, "chop"); + tdesc_add_enum_value (type_with_fields, 1, "-inf"); + tdesc_add_enum_value (type_with_fields, 2, "norm"); + tdesc_add_enum_value (type_with_fields, 3, "+inf"); + + type_with_fields = tdesc_create_flags (feature, "fpcr_flags", 8); + tdesc_add_flag (type_with_fields, 47, "DNOD"); + tdesc_add_flag (type_with_fields, 48, "DNZ"); + tdesc_add_flag (type_with_fields, 49, "INVD"); + tdesc_add_flag (type_with_fields, 50, "DZED"); + tdesc_add_flag (type_with_fields, 51, "OVFD"); + tdesc_add_flag (type_with_fields, 52, "INV"); + tdesc_add_flag (type_with_fields, 53, "DZE"); + tdesc_add_flag (type_with_fields, 54, "OVF"); + tdesc_add_flag (type_with_fields, 55, "UNF"); + tdesc_add_flag (type_with_fields, 56, "INE"); + tdesc_add_flag (type_with_fields, 57, "IOV"); + tdesc_type *field_type; + field_type = tdesc_named_type (feature, "dyn_rm_enum"); + tdesc_add_typed_bitfield (type_with_fields, "DYN_RM", 58, 59, field_type); + tdesc_add_flag (type_with_fields, 60, "UNDZ"); + tdesc_add_flag (type_with_fields, 61, "UNFD"); + tdesc_add_flag (type_with_fields, 62, "INED"); + tdesc_add_flag (type_with_fields, 63, "SUM"); + tdesc_create_reg (feature, "v0", 0, 1, NULL, 64, "int64"); tdesc_create_reg (feature, "t0", 1, 1, NULL, 64, "int64"); tdesc_create_reg (feature, "t1", 2, 1, NULL, 64, "int64"); @@ -75,7 +102,7 @@ initialize_tdesc_alpha (void) tdesc_create_reg (feature, "f28", 60, 1, "float", 64, "float"); tdesc_create_reg (feature, "f29", 61, 1, "float", 64, "float"); tdesc_create_reg (feature, "f30", 62, 1, "float", 64, "float"); - tdesc_create_reg (feature, "fpcr", 63, 1, "float", 64, "int64"); + tdesc_create_reg (feature, "fpcr", 63, 1, "float", 64, "fpcr_flags"); tdesc_create_reg (feature, "pc", 64, 1, NULL, 64, "code_ptr"); tdesc_create_reg (feature, "", 65, 0, NULL, 64, "int64"); tdesc_create_reg (feature, "unique", 66, 1, "system", 64, "int64"); -- 2.49.0 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2025-07-03 17:00 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-05-26 15:12 [PATCH 0/2] gdb/alpha: Add target description support and fpcr flags Yodel Eldar 2025-05-26 15:12 ` [PATCH 1/2] gdb/alpha: Add target description support Yodel Eldar 2025-05-26 16:13 ` Eli Zaretskii 2025-05-26 17:14 ` Yodel 2025-06-03 18:49 ` Simon Marchi 2025-06-04 13:44 ` Yodel Eldar 2025-06-04 14:49 ` Maciej W. Rozycki 2025-06-04 17:29 ` Yodel Eldar 2025-06-12 19:29 ` Yodel Eldar 2025-06-12 20:30 ` Simon Marchi 2025-06-12 20:33 ` Simon Marchi 2025-06-12 22:07 ` Yodel Eldar 2025-06-13 14:34 ` Simon Marchi 2025-06-30 0:08 ` Yodel Eldar 2025-07-02 17:14 ` Simon Marchi 2025-07-02 18:51 ` Yodel Eldar 2025-07-02 18:53 ` Maciej W. Rozycki 2025-07-02 19:02 ` Simon Marchi 2025-07-02 19:21 ` Maciej W. Rozycki 2025-07-02 20:52 ` Yodel Eldar 2025-07-02 21:12 ` Maciej W. Rozycki 2025-07-03 16:49 ` Yodel Eldar 2025-07-03 16:02 ` Simon Marchi 2025-07-02 18:48 ` Maciej W. Rozycki 2025-05-26 15:12 ` [PATCH 2/2] gdb/alpha: Redefine fpcr with fpcr_flags type Yodel Eldar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox