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