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. (This allows a target to access the host file system - which
can obviously be very useful).

> those need to be implemented on the host side _if_ the stub is going to
send them.

They need to be supported on both the host and the stub. GDB (the host)
already has support, so it's just a question of adding support to OpenOCD
(the stub).

>  And I don't see a situation when OpenOCD would send those. 

OpenOCD would send an F/X packet when it detects a system call on the target
and no O/S is running on the target. 

> Those are all user-mode signals. Since OpenOCD works on the lowest level
(JTAG), 
> it doesn't know about processes. It can only report events from hardware 
> (such as breakpoints). 
> I guess one _could_ install a custom prefetch abort handler and convert it
to a SIGBUS... 

This is essentially what I'm suggesting (although I am not doing it for
ARM). 

> but it's much more likely that OpenOCD user is debugging a kernel or an
RTOS which has its own handler.

Yes - if an OS is running then it will handle it. This would just be used in
the case where there is no OS.

I don't see any downsides to adding support for this in OpenOCD's GDB server
code. If a target doesn't support these features - it will function as is.

Cheers,
Jon


_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to