RE: [PATCH v3 05/44] gdb, gdbserver, gdbsupport: add 'device' tag to XML target description

["Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>]

Hi Simon,

On Thursday, December 18, 2025 4:04 PM, Aktemur, Tankut Baris wrote:
> Hi Simon,
> 
> On Monday, December 15, 2025 10:04 PM, Simon Marchi wrote:
> > On 12/9/25 4:27 PM, Simon Marchi wrote:
> > > On 8/1/25 5:37 AM, Tankut Baris Aktemur wrote:
> > >> From: Nils-Christian Kempke <nils-christian.kempke@intel.com>
> > >>
> > >> Add <device> tag to the XML target description.  The tag is a list
> of
> > >> device attributes.  The extension enables passing device
> information
> > >> within the target description XML sent from gdbserver to gdb.
> > >
> > > The dtd change allows a single <device> in the target description.
> > When
> > > (and if) you do multi-device debugging, you connect one inferior per
> > > device?
> 
> Yes, we represent each device as a separate inferior.
> 
> > > From the ROCm perspective: if we ever want to support remote
> debugging
> > > (no concrete plans, but we want to keep the door open to it in the
> > > design) and we end up using this attribute, I suppose we'll want to
> be
> > > able to use multiple <device> tags, since we do everything in a
> single
> > > inferior.  If so, it would be easier to support that possibility
> from
> > > the start.
> >
> > I talked about that with my team, and what I proposed doesn't make
> > sense.  The entire target description describes just one arch, it
> > wouldn't make sense to have multiple devices of possibly different
> > arches in it.
> >
> > In ROCgdb, we have an "info agents" command, which lists the agents
> > (devices) available to the current inferior (process).  You can, for
> > instance, stop at main(), and then type "info agents" to get the list.
> > Therefore, I presume that we would instead need a new kind of query,
> > "get me the list of devices", and that query could re-use the XML
> device
> > format proposed in this patch.
> 
> I agree, this sounds reasonable to me.
> 
> > Another question I have is whether the low-level details specific to
> one
> > device should really belong there in the target description.  In other
> > words, imagine that you debug with two identical devices
> simultaneously,
> > should the target descriptions for both devices be identical?  I tend
> to
> > think that they should.  Perhaps things like pci_slot shouldn't be in
> > the target description, but in a separate "device" concept outside
> > target descriptions.  Things like vendor_id and target_id allow
> > inferring details about the architecture, so I understand why it would
> > be in there.
> >
> > Simon
> 
> In our downstream debugger, we have an "info devices" command that lists
> the properties of the devices as obtained from this XML information.
> vendor_id and target_id are necessary, like you say, so that the target
> description can validate it supports that device and can do device-
> specific
> work, if necessary.  Other information is there for informing the user
> in the
> "info devices" command.  The pci_slot is useful, because if the system
> has
> multiple identical devices, pci_slot becomes the only distinguishing
> property.
> Although it is not a built-in property of the device (like number of
> cores),
> it is still physical&static -- you wouldn’t/couldn't change the pci_slot
> of a device during the debug session.  In that sense, it's a bit in the
> grey
> area.
> 
> Is pci_slot the only field that concerns you?  We can remove it from the
> patch
> and consider later.

Just pinging for this question.

Thanks,
-Baris


Intel Deutschland GmbH
Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht München HRB 186928