From: Simon Marchi <simark@simark.ca>
To: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>,
gdb-patches@sourceware.org,
Markus Metzger <markus.t.metzger@intel.com>
Subject: Re: [PATCH v3 07/44] gdb, intelgt: add the target-dependent definitions for the Intel GT architecture
Date: Thu, 11 Dec 2025 13:53:49 -0500 [thread overview]
Message-ID: <77802a4e-b72e-47fd-bb63-c084bf162331@simark.ca> (raw)
In-Reply-To: <20250801-upstream-intelgt-mvp-v3-7-59ce0f87075b@intel.com>
On 2025-08-01 05:37, Tankut Baris Aktemur wrote:
> Introduce gdb/intelgt-tdep.c for the Intel GT target. The target is
> defined in a future patch as a gdbserver low target implementation.
>
> Unlike, for example, X86-64, IntelGT does not have a dedicated
> breakpoint instruction. Instead, it has a breakpoint bit in each
> instruction. Hence, any instruction can be used as a breakpoint
> instruction.
>
> It further supports ignoring breakpoints for stepping over or resuming
> from a breakpoint. This only works, of course, if we use breakpoint
> bits inside the original instruction rather than replacing it with a
> fixed breakpoint instruction.
>
> Add gdbarch methods for inserting and removing memory breakpoints by
> setting and clearing those breakpoint bits.
>
> We define one pseudo-register, $framedesc, that provides a type alias
> for the frame descriptor register in GRF, representing it as a struct.
>
> The value of the $pc register is the $ip register, which is provided
> in $cr0.2, offset by $isabase.
>
> A translation function to map the device_id to a gen_version is
> provided. This will be useful in various places, in particular to
> generate the correct disassembly.
>
> Co-authored-by: Markus Metzger <markus.t.metzger@intel.com>
> Co-authored-by: Natalia Saiapova <natalia.saiapova@intel.com>
> Co-authored-by: Mihails Strasuns <mihails.strasuns@intel.com>
> Co-authored-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com>
Only minor comments noted below.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
> diff --git a/gdb/intelgt-tdep.c b/gdb/intelgt-tdep.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..3919947fed44c9e939bef6c14b854ae416ab7c41
> --- /dev/null
> +++ b/gdb/intelgt-tdep.c
> @@ -0,0 +1,875 @@
> +/* Target-dependent code for the Intel(R) Graphics Technology architecture.
> +
> + Copyright (C) 2019-2025 Free Software Foundation, Inc.
> +
> + This file is part of GDB.
> +
> + This program is free software; you can redistribute it and/or modify
> + it under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 3 of the License, or
> + (at your option) any later version.
> +
> + This program is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + GNU General Public License for more details.
> +
> + You should have received a copy of the GNU General Public License
> + along with this program. If not, see <http://www.gnu.org/licenses/>. */
> +
> +#include "arch-utils.h"
> +#include "arch/intelgt.h"
> +#include "cli/cli-cmds.h"
> +#include "dwarf2/frame.h"
> +#include "frame-unwind.h"
> +#include "gdbsupport/gdb_obstack.h"
gdb_obstack.h is unused.
> +/* Data specific for this architecture. */
> +
> +struct intelgt_gdbarch_tdep : gdbarch_tdep_base
> +{
> + /* $r0 GRF register number. */
> + int r0_regnum = -1;
> +
> + /* $ce register number in the regcache. */
> + int ce_regnum = -1;
> +
> + /* Register number for the GRF containing function return value. */
> + int retval_regnum = -1;
> +
> + /* Register number for the control register. */
> + int cr0_regnum = -1;
> +
> + /* Register number for the state register. */
> + int sr0_regnum = -1;
> +
> + /* Register number for the instruction base virtual register. */
> + int isabase_regnum = -1;
> +
> + /* Register number for the general state base SBA register. */
> + int genstbase_regnum = -1;
> +
> + /* Register number for the DBG0 register. */
> + int dbg0_regnum = -1;
> +
> + /* Assigned regnum ranges for DWARF regsets. */
> + regnum_range regset_ranges[intelgt::REGSET_COUNT];
> +
> + /* Enabled pseudo-registers for the current target description. */
> + std::vector<std::string> enabled_pseudo_regs;
> +
> + /* Cached $framedesc pseudo-register type. */
> + type *framedesc_type = nullptr;
> +
> + /* Initialize ranges to -1 as "not-yet-set" indicator. */
> + intelgt_gdbarch_tdep ()
> + {
> + memset (®set_ranges, -1, sizeof regset_ranges);
> + }
Instead of this memset, can you make it the default state of a
regnum_range?
struct regnum_range
{
int start = -1;
int end = -1;
};
Otherwise, I would prefer some loop that assigns {-1, -1} to each
field, rather than memset-ing objects.
Also, we usually put the constructors at the beginning...
> +
> + /* Return regnum where frame descriptors are stored. */
> + int framedesc_base_regnum ()
> + {
> + /* For EM_INTELGT frame descriptors are stored at MAX_GRF - 1. */
> + gdb_assert (regset_ranges[intelgt::REGSET_GRF].end > 1);
> + return regset_ranges[intelgt::REGSET_GRF].end - 1;
> + }
... and while we have a mixed bag of styles, I think that putting the
methods before the data members is common.
> +/* Read part of REGNUM at OFFSET into BUFFER. The length of data to
> + read is SIZE. Consider using this helper function when reading
> + subregisters of CR0, SR0, and R0. */
> +
> +static void
> +intelgt_read_register_part (readable_regcache *regcache, int regnum,
> + size_t offset,
> + gdb::array_view<gdb_byte> buffer,
> + const char *error_message)
> +{
> + if (regnum == -1)
> + error (_("%s Unexpected reg num '-1'."), error_message);
This should probably be an assert.
> +
> + gdbarch *arch = regcache->arch ();
> + const char *regname = gdbarch_register_name (arch, regnum);
> + int regsize = register_size (arch, regnum);
> +
> + if (offset + buffer.size () > regsize)
> + error (_("%s %s[%zu:%zu] is outside the range of %s[%d:0]."),
> + error_message, regname, (offset + buffer.size () - 1), offset,
> + regname, (regsize - 1));
I also wonder about this check, does it protect against bad user input,
or a bug elsewhere in GDB?
> +
> + register_status reg_status
> + = regcache->cooked_read_part (regnum, offset, buffer);
> +
> + if (reg_status == REG_UNAVAILABLE)
> + throw_error (NOT_AVAILABLE_ERROR,
> + _("%s Register %s (%d) is not available."),
> + error_message, regname, regnum);
> +
> + if (reg_status == REG_UNKNOWN)
> + error (_("%s Register %s (%d) is unknown."), error_message,
> + regname, regnum);
Does this REG_UNKNOWN case happen in real life? I always thought that
REG_UNKNOWN was the initial state of registers in the regcache, and that
after filling a regcache (a call to target_ops::fetch_registers), then
all registers would become either REG_VALID or REG_UNAVAILABLE. I
presumed that if a register was left in the REG_UNKNOWN, it would be a
target bug.
> +/* Convert a DWARF register number to a GDB register number. This
> + function requires the register listing in the target description to
> + be in the same order in each regset as the intended DWARF numbering
> + order. Currently this always holds true when gdbserver generates
> + the target description. */
> +
> +static int
> +intelgt_dwarf_reg_to_regnum (gdbarch *gdbarch, int num)
> +{
> + constexpr int ip = 0;
> + constexpr int ce = 1;
> +
> + /* Register sets follow this format: [START, END), where START is
> + inclusive and END is exclusive. */
> + constexpr regnum_range dwarf_nums[intelgt::REGSET_COUNT] = {
> + [intelgt::REGSET_SBA] = { 5, 12 },
> + [intelgt::REGSET_GRF] = { 16, 272 },
> + [intelgt::REGSET_ADDR] = { 272, 288 },
> + [intelgt::REGSET_FLAG] = { 288, 304 },
> + [intelgt::REGSET_ACC] = { 304, 320 },
> + [intelgt::REGSET_MME] = { 320, 336 },
> + };
> +
> + /* Number of SBA registers. */
> + constexpr size_t sba_dwarf_len = dwarf_nums[intelgt::REGSET_SBA].end
> + - dwarf_nums[intelgt::REGSET_SBA].start;
> +
> + /* Map the DWARF register numbers of SBA registers to their names.
> + Base number is dwarf_nums[intelgt::REGSET_SBA].start. */
> + constexpr const char* sba_dwarf_reg_order[sba_dwarf_len] {
Space before *.
> + "btbase",
> + "scrbase",
> + "genstbase",
> + "sustbase",
> + "blsustbase",
> + "blsastbase",
> + "scrbase2"
> + };
> +
> + intelgt_gdbarch_tdep *data
> + = gdbarch_tdep<intelgt_gdbarch_tdep> (gdbarch);
> +
> + if (num == ip)
> + return intelgt_pseudo_register_num (gdbarch, "ip");
> + if (num == ce)
> + return data->ce_regnum;
> +
> + for (int regset = 0; regset < intelgt::REGSET_COUNT; ++regset)
> + if (num >= dwarf_nums[regset].start && num < dwarf_nums[regset].end)
> + {
> + if (regset == intelgt::REGSET_SBA)
> + {
> + /* For SBA registers we first find out the name of the
> + register out of DWARF register number and then find the
> + register number corresponding to the name. */
> + int sba_num = num - dwarf_nums[intelgt::REGSET_SBA].start;
> + const char* name = sba_dwarf_reg_order [sba_num];
Space before *, no space before [.
> +
> + return user_reg_map_name_to_regnum (gdbarch, name, -1);
> + }
> + else
> + {
> + int candidate = data->regset_ranges[regset].start + num
> + - dwarf_nums[regset].start;
Formatting:
int candidate = (data->regset_ranges[regset].start + num
- dwarf_nums[regset].start);
> +/* The 'unwind_pc' gdbarch method. */
> +
> +static CORE_ADDR
> +intelgt_unwind_pc (gdbarch *gdbarch, const frame_info_ptr &next_frame)
> +{
> + /* Use ip register here, as IGC uses 32bit values (pc is 64bit). */
> + int ip_regnum = intelgt_pseudo_register_num (gdbarch, "ip");
> + CORE_ADDR prev_ip = frame_unwind_register_unsigned (next_frame,
> + ip_regnum);
> + intelgt_debug_printf ("prev_ip: %s", paddress (gdbarch, prev_ip));
> +
> + /* Program counter is $ip + $isabase. Read directly from the
> + regcache instead of unwinding, as the frame unwind info may
> + simply be unavailable. The isabase register does not change
> + during kernel execution, so this must be safe. */
> + regcache *regcache = get_thread_regcache (inferior_thread ());
> + CORE_ADDR isabase = intelgt_get_isabase (regcache);
Why do you not want to read isabase from NEXT_FRAME, because it's
slower? I'm asking because this use of inferior_thread slightly annoys
me.
> +/* The memory_insert_breakpoint gdbarch method. */
> +
> +static int
> +intelgt_memory_insert_breakpoint (gdbarch *gdbarch, bp_target_info *bp)
> +{
> + intelgt_debug_printf ("req ip: %s", paddress (gdbarch,
> + bp->reqstd_address));
> +
> + /* Ensure that we have enough space in the breakpoint. */
> + static_assert (intelgt::MAX_INST_LENGTH <= BREAKPOINT_MAX);
> +
> + gdb_byte inst[intelgt::MAX_INST_LENGTH];
> + int err = target_read_memory (bp->reqstd_address, inst,
> + intelgt::MAX_INST_LENGTH);
> + if (err != 0)
> + {
> + /* We could fall back to reading a full and then a compacted
> + instruction but I think we should rather allow short reads than
> + having the caller try smaller and smaller sizes. */
Please avoid the first person in comments (there is at least one other
instance).
> +/* The memory_remove_breakpoint gdbarch method. */
> +
> +static int
> +intelgt_memory_remove_breakpoint (gdbarch *gdbarch, struct bp_target_info *bp)
> +{
> + intelgt_debug_printf ("req ip: %s, placed ip: %s",
> + paddress (gdbarch, bp->reqstd_address),
> + paddress (gdbarch, bp->placed_address));
> +
> + /* Warn if we're inserting a permanent breakpoint. */
inserting -> removing?
> +/* The "read_pc" gdbarch method. */
> +
> +static CORE_ADDR
> +intelgt_read_pc (readable_regcache *regcache)
> +{
> + gdbarch *arch = regcache->arch ();
> + intelgt_gdbarch_tdep *data = gdbarch_tdep<intelgt_gdbarch_tdep> (arch);
> +
> + /* Instruction pointer is stored in CR0.2. */
> + uint32_t ip;
> + intelgt_read_register_part (regcache, data->cr0_regnum,
> + sizeof (uint32_t) * 2,
> + gdb::make_array_view ((gdb_byte *) &ip,
> + sizeof (uint32_t)),
> + _("Cannot compute PC."));
Even though we know the host will likely always be little-endian, this
is not technically correct. There should be an extract_unsigned_integer
call (or equivalent) to extract the target bytes into the host variable.
Same for other functions that read or update the PC using
make_array_view.
> +/* Called by tdesc_use_registers each time a new regnum
> + is assigned. Used to track down assigned numbers for
> + any important regnums. */
> +
> +static int
> +intelgt_unknown_register_cb (gdbarch *arch, tdesc_feature *feature,
> + const char *reg_name, int possible_regnum)
> +{
> + intelgt_gdbarch_tdep *data = gdbarch_tdep<intelgt_gdbarch_tdep> (arch);
> +
> + /* First, check if this a beginning of a not yet tracked regset
> + assignment. */
> +
> + for (int regset = 0; regset < intelgt::REGSET_COUNT; ++regset)
> + {
> + if (data->regset_ranges[regset].start == -1
> + && feature->name == intelgt::DWARF_REGSET_FEATURES[regset])
> + {
> + data->regset_ranges[regset].start = possible_regnum;
> + data->regset_ranges[regset].end
> + = feature->registers.size () + possible_regnum;
> + break;
> + }
> + }
You can get rid of the braces for the "for".
> +/* Architecture initialization. */
> +
> +static gdbarch *
> +intelgt_gdbarch_init (gdbarch_info info, gdbarch_list *arches)
> +{
> + /* If there is already a candidate, use it. */
> + arches = gdbarch_list_lookup_by_info (arches, &info);
> + if (arches != nullptr)
> + return arches->gdbarch;
> +
> + const target_desc *tdesc = info.target_desc;
> + gdbarch_up gdbarch_u
> + (gdbarch_alloc (&info,
> + gdbarch_tdep_up (new intelgt_gdbarch_tdep)));
> + gdbarch *gdbarch = gdbarch_u.get ();
> + intelgt_gdbarch_tdep *data
> + = gdbarch_tdep<intelgt_gdbarch_tdep> (gdbarch);
> +
> + /* Initialize register info. */
> + set_gdbarch_num_regs (gdbarch, 0);
> + set_gdbarch_register_name (gdbarch, tdesc_register_name);
> +
> + if (tdesc_has_registers (tdesc))
> + {
> + tdesc_arch_data_up tdesc_data = tdesc_data_alloc ();
> +
> + /* First assign register numbers to all registers. The
> + callback function will record any relevant metadata
> + about it in the intelgt_gdbarch_data instance to be
> + inspected after. */
> +
> + tdesc_use_registers (gdbarch, tdesc, std::move (tdesc_data),
> + intelgt_unknown_register_cb);
Might as well inline the call to tdesc_data_alloc.
> +
> + /* Now check the collected metadata to ensure that all
> + mandatory pieces are in place. */
> +
> + if (data->ce_regnum == -1)
> + error (_("Debugging requires $ce provided by the target"));
Missing "to be".
> + if (data->retval_regnum == -1)
> + error (_("Debugging requires return value register to be provided "
> + "by the target"));
> + if (data->cr0_regnum == -1)
> + error (_("Debugging requires control register to be provided by "
> + "the target"));
> + if (data->sr0_regnum == -1)
> + error (_("Debugging requires state register to be provided by "
> + "the target"));
> +
> + /* Unconditionally enabled pseudo-registers: */
> + data->enabled_pseudo_regs.push_back ("ip");
> + data->enabled_pseudo_regs.push_back ("framedesc");
> +
> + set_gdbarch_num_pseudo_regs (gdbarch, data->enabled_pseudo_regs.size ());
> + set_gdbarch_pseudo_register_read_value (
> + gdbarch, intelgt_pseudo_register_read_value);
Opening parenthesis on next line.
Simon
next prev parent reply other threads:[~2025-12-11 18:54 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-01 9:37 [PATCH v3 00/44] A new target to debug Intel GPUs Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 01/44] gdb, intelgt: add intelgt as a basic machine Tankut Baris Aktemur
2025-12-09 20:44 ` Simon Marchi
2025-12-19 11:13 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 02/44] bfd: add intelgt target to BFD Tankut Baris Aktemur
2025-08-01 12:20 ` Jan Beulich
2025-08-08 5:03 ` Metzger, Markus T
2025-12-09 21:05 ` Simon Marchi
2025-12-19 12:46 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 03/44] ld: add intelgt as a target configuration Tankut Baris Aktemur
2025-08-01 12:06 ` Jan Beulich
2025-08-08 5:03 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 04/44] opcodes: add intelgt as a configuration Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 05/44] gdb, gdbserver, gdbsupport: add 'device' tag to XML target description Tankut Baris Aktemur
2025-12-09 21:27 ` Simon Marchi
2025-12-15 21:03 ` Simon Marchi
2025-12-18 15:04 ` Aktemur, Tankut Baris
2026-01-09 19:12 ` Aktemur, Tankut Baris
2026-01-09 19:34 ` Simon Marchi
2025-08-01 9:37 ` [PATCH v3 06/44] gdb, arch, intelgt: add intelgt arch definitions Tankut Baris Aktemur
2025-12-09 21:48 ` Simon Marchi
2025-12-16 15:47 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 07/44] gdb, intelgt: add the target-dependent definitions for the Intel GT architecture Tankut Baris Aktemur
2025-12-11 18:53 ` Simon Marchi [this message]
2025-12-19 16:01 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 08/44] gdb, intelgt: add disassemble feature " Tankut Baris Aktemur
2025-12-11 19:37 ` Simon Marchi
2025-12-23 11:03 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 09/44] gdb, gdbserver, ze: in-memory libraries Tankut Baris Aktemur
2025-12-12 4:13 ` Simon Marchi
2025-12-12 11:20 ` Metzger, Markus T
2025-12-12 19:34 ` Simon Marchi
2025-12-15 13:07 ` Metzger, Markus T
2025-12-15 21:25 ` Simon Marchi
2025-08-01 9:37 ` [PATCH v3 10/44] gdb, gdbserver, rsp, ze: acknowledge libraries Tankut Baris Aktemur
2025-12-12 4:41 ` Simon Marchi
2025-12-12 14:28 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 11/44] gdb, solib, ze: update target_solib_ops::bfd_open_from_target_memory Tankut Baris Aktemur
2025-12-12 4:43 ` Simon Marchi
2025-12-12 14:33 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 12/44] gdb, infrun, ze: allow saving process events Tankut Baris Aktemur
2025-12-12 4:57 ` Simon Marchi
2025-12-15 13:13 ` Metzger, Markus T
2025-12-16 21:10 ` Simon Marchi
2025-12-17 9:30 ` Metzger, Markus T
2025-12-17 20:44 ` Simon Marchi
2025-12-18 7:20 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 13/44] gdb, ze: add TARGET_WAITKIND_UNAVAILABLE Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 14/44] gdb, infrun, ze: handle stopping unavailable threads Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 15/44] gdb, infrun, ze: allow resuming " Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 16/44] gdb, gdbserver, ze: add U stop reply Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 17/44] gdb, gdbserver, ze: add library notification to " Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 18/44] gdbserver, ze: report TARGET_WAITKIND_UNAVAILABLE events Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 19/44] gdb, ze: handle TARGET_WAITKIND_UNAVAILABLE in stop_all_threads Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 20/44] gdb, remote: handle thread unavailability in print_one_stopped_thread Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 21/44] gdb, remote: do 'remote_add_inferior' in 'remote_notice_new_inferior' earlier Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 22/44] gdb, remote: handle a generic process PID in remote_notice_new_inferior Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 23/44] gdb, remote: handle a generic process PID in process_stop_reply Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 24/44] gdb: use the pid from inferior in setup_inferior Tankut Baris Aktemur
2025-12-12 19:51 ` Simon Marchi
2025-12-13 12:40 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 25/44] gdb: revise the pid_to_exec_file target op Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 26/44] gdb: load solibs if the target does not have the notion of an exec file Tankut Baris Aktemur
2025-12-12 20:30 ` Simon Marchi
2026-01-09 19:10 ` Aktemur, Tankut Baris
2025-08-01 9:37 ` [PATCH v3 27/44] gdbserver: import AC_LIB_HAVE_LINKFLAGS macro into the autoconf script Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 28/44] gdbserver: add a pointer to the owner thread in regcache Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 29/44] gdbserver: wait for stopped threads in queue_stop_reply_callback Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 30/44] gdbserver: adjust pid after the target attaches Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 31/44] gdb: do not create a thread after a process event Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 32/44] gdb, ze: on a whole process stop, mark all threads as not_resumed Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 33/44] gdb, dwarf, ze: add DW_OP_INTEL_regval_bits Tankut Baris Aktemur
2025-08-01 12:02 ` Jan Beulich
2025-08-01 12:31 ` Metzger, Markus T
2025-08-01 12:50 ` Jan Beulich
2025-08-08 5:25 ` Metzger, Markus T
2025-08-01 9:37 ` [PATCH v3 34/44] gdbserver: allow configuring for a heterogeneous target Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 35/44] gdbserver, ze, intelgt: introduce ze-low and intel-ze-low targets Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 36/44] testsuite, sycl: add SYCL support Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 37/44] testsuite, sycl: add test for backtracing inside a kernel Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 38/44] testsuite, sycl: add test for 'info locals' and 'info args' Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 39/44] testsuite, sycl: add tests for stepping and accessing data elements Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 40/44] testsuite, sycl: add test for 1-D and 2-D parallel_for kernels Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 41/44] testsuite, sycl: add test for scheduler-locking Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 42/44] testsuite, arch, intelgt: add a disassembly test Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 43/44] testsuite, arch, intelgt: add intelgt-program-bp.exp Tankut Baris Aktemur
2025-08-01 9:37 ` [PATCH v3 44/44] testsuite, sycl: test canceling a stepping flow Tankut Baris Aktemur
2025-09-17 12:43 ` [PATCH v3 00/44] A new target to debug Intel GPUs Aktemur, Tankut Baris
2025-10-14 6:34 ` Aktemur, Tankut Baris
2025-12-08 11:32 ` Aktemur, Tankut Baris
2025-12-09 21:30 ` Simon Marchi
2025-12-19 12:52 ` Aktemur, Tankut Baris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77802a4e-b72e-47fd-bb63-c084bf162331@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=tankut.baris.aktemur@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox