https://bugs.kde.org/show_bug.cgi?id=473687
--- Comment #1 from Alexandra Hajkova <[email protected]> --- Created attachment 185799 --> https://bugs.kde.org/attachment.cgi?id=185799&action=edit patch New qExecAndArgs packet has been added recently to GDB's remote protocol. The new qExecAndArgs packet is sent from GDB, and gdbserver replies with a packet that includes the executable filename and the arguments string that were used for starting the initial inferior. On the GDB side this information can be used to update GDB's state, the 'show remote exec-file' will reflect how gdbserver was started, and 'show args' will reflect the arguments used for starting the inferior. When running Valgrind from inside GDB, we can see that GDB actually sends the packet to vgdb and vgdb is able to respond to it. gdb -ex 'set debug remote on' \ -ex 'set remote exec-file /bin/ls' \ -ex 'set sysroot /' \ -ex 'target extended-remote | ~/valgrind/coregrind/vgdb --multi --vargs -q' \ /bin/ls [remote] Sending packet: $qExecAndArgs#96 [remote] Packet received: U [remote] packet_ok: Packet qExecAndArgs (fetch-exec-and-args) is supported To be able to run Valgrind from inside GDB we currently have to set remote exec-file and our goal is to avoid that to make running Valgrind from GDB easier for the users. There's work on GDB side which should allow us to avoid this soon. When vgdb replies with 'U', it indicates that no executable has been set. GDB sees that the executable that it has loaded is inside the sysroot (which we set with 'set sysroot /'), then GDB knows that the remote and GDB can see the same file. GDB will then automatically use the current executable path as the remote exec-file value. -- You are receiving this mail because: You are watching all bug changes.
