> What do you believe other OpenOCD users could use such file IO for?
>
> I have used it in the past when running test suites that
> require test large vectors & writing back test results
> that don't fit/should not be stored on the target but
> rather the GDB host. Not the sort of thing that I e
Hi David,
> To handle syscalls ... use a GDB server (or stub)
> running native in that OS. Not on bare metal, not talking over JTAG.
But that could use up precious resources that you might not have (memory and
I/O). Also, why should you have to switch to software based debugging (Which
might n
Hi,
The attached patch adds support for the GDB File I/O Remote Protocol as well
as allowing a target to return various signal numbers, as I mentioned last
week.
This patch doesn't actually add support for these features to any of the
existing targets (ARM/MIPS), but just provides the hooks to d
Hi Igor,
> The GDB "server in OpenOCD is what is called "stub" in the documentation.
Agreed.
> It does not need to support F or X;
It doesn't need to do. But if you want to support the File I/O Remote
Protocol (http://sourceware.org/gdb/current/onlinedocs/gdb_34.html#SEC734)
then it does. (T
Hi,
I'm porting OpenOCD to a new processor architecture and I've noticed that
there doesn't appear to be any support for the X and F GDB Stop Reply
Packets (http://sourceware.org/gdb/current/onlinedocs/gdb_34.html#SEC724),
which are used to indicate that a process has exited (X) or to perform
syst
