From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
Subject: RE: [PATCH v2 11/47] gdb, gdbserver, rsp, ze: acknowledge libraries
Date: Thu, 31 Jul 2025 06:09:52 +0000 [thread overview]
Message-ID: <DM8PR11MB57490D0E82DB7ACAD9952DF1DE27A@DM8PR11MB5749.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87y0sodaxa.fsf@linaro.org>
Hello Thiago,
Thanks for your review.
>> @@ -48084,16 +48141,18 @@ The format of a library list is described by this
>DTD:
>> @smallexample
>> <!-- library-list: Root element with versioning -->
>> <!ELEMENT library-list (library | in-memory-library)*>
>> -<!ATTLIST library-list version CDATA #FIXED "1.1">
>> +<!ATTLIST library-list version CDATA #FIXED "1.2">
>> <!ELEMENT library (segment*, section*)>
>> -<!ATTLIST library name CDATA #REQUIRED>
>> +<!ATTLIST library name CDATA #REQUIRED
>> + ack (yes | no) 'no'>
>> <!ELEMENT in-memory-library (segment*, section*)>
>> -<!ATTLIST in-memory-library begin CDATA #REQUIRED
>> - end CDATA #REQUIRED>
>> +<!ATTLIST in-memory-library begin CDATA #REQUIRED
>> + end CDATA #REQUIRED
>> + ack (yes | no) 'no'>
>> <!ELEMENT segment EMPTY>
>> -<!ATTLIST segment address CDATA #REQUIRED>
>> +<!ATTLIST segment address CDATA #REQUIRED>
>> <!ELEMENT section EMPTY>
>> -<!ATTLIST section address CDATA #REQUIRED>
>> +<!ATTLIST section address CDATA #REQUIRED>
>> @end smallexample
>
>I would move the last column (the one with "#FIXED", "#REQUIRED" and
>'no') a couple more spaces to the right. The change above leaves them
>right next to "(segment*, section*)>" and it feels a bit crowded IMHO.
I assume you mean moving all the existing entries to the right so they all
align again.
>> +static void
>> +ack_dll (process_info *process, dll_info &dll)
>> +{
>> + gdb_assert (dll.need_ack);
>> +
>> + switch (dll.location)
>> + {
>> + case dll_info::on_disk:
>> + /* Check if this is a temporary file for an in-memory library. */
>> + if (dll.begin == UNSPECIFIED_CORE_ADDR)
>> + {
>> + target_ack_library (process, dll.name.c_str ());
>> + dll.need_ack = false;
>> + return;
>> + }
>> +
>> + [[fallthrough]];
>> + case dll_info::in_memory:
>> + target_ack_in_memory_library (process, dll.begin, dll.end);
>> + dll.need_ack = false;
>> + return;
>> + }
>
>I'm confused by this switch statement. So a vAck:library packet will be
>used only if it's for an in-memory library and vAck:in-memory-library
>isn't supported? I would think that a vAck:library would also be used
>for an on-disk library.
vAck:library is the default for on-disk libraries. There's one special case,
though. If the target provided an in-memory library and we created a
temporary file for it, GDB will acknowledge it using vAck:library, but we
want to acknowledge it as in-memory library to our target, since that's
what the target provided.
The check is wrong, though. It should be (dll.begin == 0) as on-disk libraries
are initialized with begin = 0. We do not expect in-memory libraries to start
at zero.
This is not covered by automated testing since both GDB and gdbserver support
in-memory libraries for our target. I tested the v3 version manually by disabling
in-memory library support in our GDB.
See my comment in the reply to patch 10. Since our target does not need that
fall-back, we could remove it and have someone else add it for their target if they
need it. This way, we will have a natural way of testing it. But then, testing
combinations of GDB and gdbserver is and will remain a challenge.
>> +ack_dll (process_info *proc, CORE_ADDR begin, CORE_ADDR end)
>> +{
>> + std::list<dll_info> &dlls = proc->all_dlls;
>> + std::list<dll_info>::iterator it
>> + = std::find_if (dlls.begin (), dlls.end (),
>> + [begin, end] (const dll_info &dll)
>> + {
>> + /* For root devices with multiple sub-devices, modules with
>> + identical start/end addresses may be received for different
>> + sub-devices. Therefore we check for the 'NEED_ACK' flag in
>> + the search, too. */
>
>And is it guaranteed that only one of them will have need_ack set to
>true? Can you explain that in the comment?
This is simply wrong. I suspect this is a workaround that sneaked in as
a fixup a long time ago when the stack was less mature and we have not
spotted it when we prepared the patch series for submission.
For root devices with multiple sub-devices and mirrored module heaps,
we indeed load the same device library multiple times, but either GDB
represents each sub-device as a separate inferior, so they would be on
different dll lists, or the stack below GDB would be responsible for
presenting a single virtual module to GDB.
In theory, you could load the same library at different base addresses,
so we could argue that we'd want the base address in the comparison.
And maybe the dynamic linker namespace, too.
We support none of that in our target, so this would be completely
untested and arguably overengineered.
In v3, I remove the need_ack check and make loaded_dll() error out
when called with a duplicate in-memory library so we don't run into
silent errors here.
>> +/* Parse vAck packets. */
>> +
>> +static void
>> +handle_v_ack (char *own_buf)
>> +{
>> + client_state &cs = get_client_state ();
>> + char *p;
>> +
>> + /* Move past vAck: to the first type string. */
>> + p = &own_buf[5];
>> + do
>> + {
>> + if (cs.vack_library_supported
>> + && (strncmp (p, "library:", strlen ("library:")) == 0))
>> + {
>> + p += strlen ("library:");
>> +
>> + /* We expect a single argument: the filename. */
>> + const char *name = p;
>> + p = strchr (p, ';');
>> + if (p != nullptr)
>> + *p++ = '\0';
>> +
>> + ack_dll (name);
>
>The documentation for vAck says:
>
> Acknowledge a ‘;’-separated list of remote stub responses, each with a
> ‘,’- separated list of arguments defined by its type.
>
>But the above will consider everything between the ':' and ';' to be the
>library name, even if there's a ','. I think you should check whether
>there's a ',' in name, and if so either reject the packet or ignore the
>additional arguments — not sure which is better, I'm leaning towards
>rejecting the packet.
Common practice seems to be to encode filenames in RSP packets
as hex-encoded strings. I'll follow that.
>> + }
>> + else if (cs.vack_in_memory_library_supported
>> + && (strncmp (p, "in-memory-library:",
>> + strlen ("in-memory-library:")) == 0))
>> + {
>> + p += strlen ("in-memory-library:");
>> +
>> + /* We expect two arguments: begin and end address. */
>> + CORE_ADDR begin, end;
>> +
>> + begin = (CORE_ADDR) strtoull (p, &p, 16);
>> + if (*p != ',')
>> + break;
>
>If this break is taken and begin is the last argument in the packet,
>then won't *p == 0 and cause write_ok () to be called below? An error
>should be returned instead.
I agree. Thanks.
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2025-07-31 6:12 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 15:59 [PATCH v2 00/47] A new target to debug Intel GPUs Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 01/47] gdb, intelgt: add intelgt as a basic machine Tankut Baris Aktemur
2024-12-16 7:53 ` Jan Beulich
2024-12-17 18:48 ` Aktemur, Tankut Baris
2024-12-18 7:19 ` Jan Beulich
2024-12-20 9:55 ` Aktemur, Tankut Baris
2025-02-03 17:17 ` Aktemur, Tankut Baris
2025-02-04 7:06 ` Jan Beulich
2024-12-13 15:59 ` [PATCH v2 02/47] bfd: add intelgt target to BFD Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 03/47] ld: add intelgt as a target configuration Tankut Baris Aktemur
2024-12-16 7:43 ` Jan Beulich
2024-12-13 15:59 ` [PATCH v2 04/47] opcodes: add intelgt as a configuration Tankut Baris Aktemur
2024-12-16 7:44 ` Jan Beulich
2024-12-17 18:47 ` Aktemur, Tankut Baris
2024-12-18 7:22 ` Jan Beulich
2024-12-20 9:47 ` Aktemur, Tankut Baris
2025-01-03 4:46 ` Simon Marchi
2025-02-03 17:13 ` Aktemur, Tankut Baris
2025-02-04 7:07 ` Jan Beulich
2024-12-13 15:59 ` [PATCH v2 05/47] gdb, arch, intelgt: add intelgt arch definitions Tankut Baris Aktemur
2025-07-08 3:03 ` Thiago Jung Bauermann
2025-07-21 10:49 ` Aktemur, Tankut Baris
2024-12-13 15:59 ` [PATCH v2 06/47] gdb, intelgt: add the target-dependent definitions for the Intel GT architecture Tankut Baris Aktemur
2025-07-08 2:43 ` Thiago Jung Bauermann
2025-07-18 17:43 ` Aktemur, Tankut Baris
2024-12-13 15:59 ` [PATCH v2 07/47] gdb, gdbserver, gdbsupport: add 'device' tag to XML target description Tankut Baris Aktemur
2024-12-13 16:45 ` Eli Zaretskii
2025-07-08 4:04 ` Thiago Jung Bauermann
2025-07-21 10:49 ` Aktemur, Tankut Baris
2024-12-13 15:59 ` [PATCH v2 08/47] gdb, intelgt: add disassemble feature for the Intel GT architecture Tankut Baris Aktemur
2025-07-09 3:12 ` Thiago Jung Bauermann
2024-12-13 15:59 ` [PATCH v2 09/47] gdbsupport, filestuff, ze: temporary files Tankut Baris Aktemur
2025-07-14 1:26 ` Thiago Jung Bauermann
2024-12-13 15:59 ` [PATCH v2 10/47] gdb, gdbserver, ze: in-memory libraries Tankut Baris Aktemur
2025-07-14 2:35 ` Thiago Jung Bauermann
2025-07-31 6:09 ` Metzger, Markus T
2025-07-16 4:08 ` Thiago Jung Bauermann
2024-12-13 15:59 ` [PATCH v2 11/47] gdb, gdbserver, rsp, ze: acknowledge libraries Tankut Baris Aktemur
2024-12-13 16:43 ` Eli Zaretskii
2025-07-16 4:20 ` Thiago Jung Bauermann
2025-07-31 6:09 ` Metzger, Markus T [this message]
2024-12-13 15:59 ` [PATCH v2 12/47] gdb, solib, ze: solib_bfd_open_from_target_memory Tankut Baris Aktemur
2025-07-18 0:42 ` Thiago Jung Bauermann
2024-12-13 15:59 ` [PATCH v2 13/47] gdb, remote, ze: fix "$Hc-1#09...Packet received: E01" during startup Tankut Baris Aktemur
2025-07-18 0:41 ` Thiago Jung Bauermann
2025-08-01 7:55 ` Metzger, Markus T
2024-12-13 15:59 ` [PATCH v2 14/47] gdb, infrun, ze: allow saving process events Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 15/47] gdb, ze: add TARGET_WAITKIND_UNAVAILABLE Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 16/47] gdb, infrun, ze: handle stopping unavailable threads Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 17/47] gdb, infrun, ze: allow resuming " Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 18/47] gdb, gdbserver, ze: add U stop reply Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 19/47] gdb, gdbserver, ze: add library notification to " Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 20/47] gdbserver, ze: report TARGET_WAITKIND_UNAVAILABLE events Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 21/47] gdb, ze: handle TARGET_WAITKIND_UNAVAILABLE in stop_all_threads Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 22/47] gdb, remote: handle thread unavailability in print_one_stopped_thread Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 23/47] gdb, remote: do 'remote_add_inferior' in 'remote_notice_new_inferior' earlier Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 24/47] gdb, remote: handle a generic process PID in remote_notice_new_inferior Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 25/47] gdb, remote: handle a generic process PID in process_stop_reply Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 26/47] gdb: use the pid from inferior in setup_inferior Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 27/47] gdb: revise the pid_to_exec_file target op Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 28/47] gdb: load solibs if the target does not have the notion of an exec file Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 29/47] gdbserver: import AC_LIB_HAVE_LINKFLAGS macro into the autoconf script Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 30/47] gdbserver: add a pointer to the owner thread in regcache Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 31/47] gdbserver: dump 'xx...x' in collect_register_as_string for unavailable register Tankut Baris Aktemur
2024-12-23 11:38 ` Aktemur, Tankut Baris
2024-12-23 13:47 ` Luis Machado
2024-12-13 15:59 ` [PATCH v2 32/47] gdbserver: wait for stopped threads in queue_stop_reply_callback Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 33/47] gdbserver: adjust pid after the target attaches Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 34/47] gdb: do not create a thread after a process event Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 35/47] gdb, ze: on a whole process stop, mark all threads as not_resumed Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 36/47] gdb, dwarf, ze: add DW_OP_INTEL_regval_bits Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 37/47] gdbserver: allow configuring for a heterogeneous target Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 38/47] gdbserver, ze, intelgt: introduce ze-low and intel-ze-low targets Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 39/47] testsuite, sycl: add SYCL support Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 40/47] testsuite, sycl: add test for backtracing inside a kernel Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 41/47] testsuite, sycl: add test for 'info locals' and 'info args' Tankut Baris Aktemur
2024-12-13 15:59 ` [PATCH v2 42/47] testsuite, sycl: add tests for stepping and accessing data elements Tankut Baris Aktemur
2024-12-13 16:00 ` [PATCH v2 43/47] testsuite, sycl: add test for 1-D and 2-D parallel_for kernels Tankut Baris Aktemur
2024-12-13 16:00 ` [PATCH v2 44/47] testsuite, sycl: add test for scheduler-locking Tankut Baris Aktemur
2024-12-13 16:00 ` [PATCH v2 45/47] testsuite, arch, intelgt: add a disassembly test Tankut Baris Aktemur
2024-12-13 16:00 ` [PATCH v2 46/47] testsuite, arch, intelgt: add intelgt-program-bp.exp Tankut Baris Aktemur
2024-12-13 16:00 ` [PATCH v2 47/47] testsuite, sycl: test canceling a stepping flow Tankut Baris Aktemur
2025-02-07 10:18 ` [PATCH v2 00/47] A new target to debug Intel GPUs Aktemur, Tankut Baris
2025-05-08 7:40 ` Aktemur, Tankut Baris
2025-05-26 8:03 ` Aktemur, Tankut Baris
2025-06-17 12:22 ` Aktemur, Tankut Baris
2025-07-03 12:55 ` 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=DM8PR11MB57490D0E82DB7ACAD9952DF1DE27A@DM8PR11MB5749.namprd11.prod.outlook.com \
--to=markus.t.metzger@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=tankut.baris.aktemur@intel.com \
--cc=thiago.bauermann@linaro.org \
/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