Øyvind> Once there are some polymorph proc's defined, I'd like to update the Zylin Øyvind> Embedded CDT to support them. This will allow showing and even modifying Øyvind> peripherals from a GDB GUI frontend.
duane> This should use the interface Charles is creating. Øyvind> I don't want to set up anything else but the GDB connection, more hazzle Øyvind> for the user, so I'd like to do any communication using the GDB Øyvind> monitor command. Øyvind> Would that be a problem? Yes, and no. First - the "MON" command is the same as TELNET - you just do not have to prefix your commands with mon. Basically what I proposed in my earlier email in response to Charles - is a programmatic machine interface to the "telnet prompt" that simplifies parsing. Second, the telnet interface is great for a human but it is not a programmatic machine interface. You cannot tell success, and you cannot tell failure. You must parse english prose - if you get any. yes, that does work - but it is painful and complicated to write for. Third - nothing gets rid of the "mon" type interface. Or the telnet inter face. But - they both suffer from a "connection state". See below. NO - because - if GDB is the remote agent talking to OPENOCD - then GDB can do what ever it feels like. YES - because GDB is active - an external program cannot access memory to do something like "display memory as a jpeg". For example - what if I am using DDD - w/ gdb-arm remote? or KDBUG - I certianly cannot get these features added there. Or - if I am using IAR (Like Simon Qian is using) there would be no way for an external tool to access memory. About the "connection state problem" yes - I could "disconnect GDB" - run my tool - but - when I reconnect GDB - GDB wants to re-download my app. I loose my debug state. If On the other hand we apply the *simple* rule - The human (doing the debugging) must enforce some amount of exclusive access. ie: If I stop GDB, something else can display memory. GDB does not need to know. We could improve that a great deal - with the programatic interface - by returning a defined "BUSY" error if the target is busy (ie: running under GDB control) In addition, the "programmatic interface" effectively holds no state. A program while connected - holds an exclusive lock. That "image display program" can and should disconnect and reconnect at will. -Duane. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
