Hi Igor,
> JB> However, I'd really like something which would allow custom RSP
> JB> commands (which can write back to the socket) to be handled.
> JB> The problems I see are that, even though the gdb_put_packet() function
> JB> is declared and could be used by target code, I can't, for the life of
> JB> me, figure out where I could get the right connection* to be putting
> JB> the data out at the right place. Also, the unconditional "OK" being
> JB> sent isn't great either - perhaps that could be conditional on a
> JB> return value from command_run_line() or something.
>
> I'm quite sure you can send a different response for qRcmd - that's how
> you can use the usual "telnet" interface from inside GDB. Otherwise
> have a look at the File-I/O Remote Protocol Extension or qXfer commands.
I'd really like to just be able to do something like the following in
my registered command handler:
1) Extract the register address from the command string
2) Do the access to the CPU
3) Format the read value into ASCII and call gdb_put_packet() to write it back.
The problem is I can't call gdb_put_packet() from my target-specific
command because the required struct connection* isn't passed to the
command handler. These go through command_line_run() which is actually
turning it into a TCL command call.
I figure I shouldn't be putting in architecture-specific stuff to the
generic RSP server code, so I can't figure out the best way to do
this, other than perhaps making the current connection a global, which
I also have a feeling would be bad.
Have I missed something, or am I more likely to find a better solution
by changing our GDB port?
Thanks,
Julius
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
