Getting default program path

[eloycoto]

Is there any way to get the default program path using gdbstub?

In the ExtendedMode, there is run method, but filename is only present if it's not the default program.

https://docs.rs/gdbstub/latest/gdbstub/target/ext/extended_mode/trait.ExtendedMode.html#tymethod.run

I would like to implement "load" command, I have a POC with monitor load elf.path, but I would like to avoid the filename in the gdb config if it's possible, but getting the default program path sems impossible, or I do not find the way.

To clarify:

target extended-remote :1337

monitor load

gdb -q -x config.gdb ./target/program.elf

I would like to get the ./target/program.elf inside the monitorCmd trait.

Any hint?

[daniel5151]

This could very well be related to baseline GDB RSP semantics, as opposed to anything gdbstub specific. While gdbstub certainly attempts to make various APIs more "ergonomic", it's not in the business of omitting information from end-users, so if you're not getting this info, its likely the GDB client simply isn't sending over.

If your gdbstub integration has support for emitting log-based logs, you can configure your logger to dump incoming/output GDB RSP traffic by setting the the trace level of the gdbstub module to trace. Alternatively, you can view traffic on the GDB-side by running set debug remote 1 prior to target extended-remote :1337. Maybe the data is being sent, but not acted on due to a missing extension?

Alternatively, you can see if there are some client-side changes you can make to get it to send you the info you're interested in.

Aside from those generic pointers, I'm afraid I don't have any concrete hints to give here 😅

[eloycoto]

No, it's not sending it over. I reviewed logs & gdb logs, and data is not around.

If I find the way I'll add a comment here :-)

Regards

[bet4it]

Why not use exec-file? #69