Community
Participate
Working Groups
We are using gdb's "monitor" commands to query some internal information of our debug target. The guidelines in the gdb manual are to extend the serial protocol by modifying the gdb stub (only, without modifying gdb) to understand new monitor commands. Monitor commands are sent as $qRcmd packets. Responses are to be sent as "$O" packets. gdb outputs these with the token "@", i.e. as belonging to the target output stream. Here is a sample of "monitor mbox", a newly introduced command which reports the status the OS's mailboxes: =======snip================== [1,133,772,933,238] (gdb) [1,133,772,936,751] 61 monitor mbox [1,133,772,936,753] &"monitor mbox\n" [1,133,772,936,787] @"Box at 0x320dd56c: 0 messages\n" [1,133,772,936,798] @"Total 1 boxes\n" [1,133,772,936,802] 61^done [1,133,772,936,803] (gdb) =======snap================== Now in order to use this command from eclipse and populate a new debug view from the output we created the usual CLICommand - MIInfo pair and posted the command via the MISession. Everything works fine except that the records containing the real information are not there. They are not collected in org.eclipse.cdt.debug.mi.core.RxThread.processMIOOBRecord(MIStreamRecord stream) where the three possible output streams are processed. The current implementation is: Console stream output: echo to console and collect as OOB record. Log stream output: echo to console and collect as OOB record. Target stream output: just echo to console. The proposal is to add collecting as OOB record to the third alternative. This will make the output of any monitor commands that are present in a target, or that can be added by extending the gdb stub, available for automatic processing in the CDT debugging framework.
Alternate implementation suggestion from Mikhail Khodjaiants: > The alternative solution would be the addition of a special MI command for this. Is it doable? I would rather have the enhancement along the lines I suggested above for the following reasons: 1) The proposal needs to extend the gdb stub only. The stub is made for adaptation and the adaptation procedure is described in the manual so we are assured that the gdb folk are aware of and will be supporting our approach. 2) The proposal makes existing "monitor" commands available for CDT debug views along with those which are newly created. More comments Mikhail? (Or anybody?)
(In reply to comment #1) > More comments Mikhail? (Or anybody?) Just a simple question: do you need this for 3.0.2 or 3.1?
No special hurry, I can go by using a patched version of RxThread. I just want to be sure that it will not be forgotten on the long road to version 3.1. I understand that fixes for 3.1 go to HEAD and that there is a branch for 3.0.2 and I guess I am happiest if you do the fix now, although it's sufficient to do it in HEAD only. Thanks a lot!
What if do it this way: I'll set the target milestone to 3.1 and you try the patched version and we'll see if there are some side effects. I didn't write this code and I'm not very comfortable changing it until I learn more. Is this OK with you?
Fine, just let me know when you've applied the patches.
Hey Michail, with my changed status I could now do the patch in case you don't find the time. Shall I? Norbert
Norbert, Currently, I am making major changes in mi plugins and I don't want to commit it until I am done with it. Merging is a pain and takes a lot of time. Please, wait I'll let you know when it is save. Thanks, Mikhail
Supporting the GDB "monitor" command is an important feature for embedded development. Seems to work fine on my rocket. I'm using a BDI 2000 JTAG debugger and I took some simple "monitor" commands for a spin. (gdb) monitor info Core number : 0 Core state : debug mode (ARM) Debug entry cause : Breakpoint Current PC : 0x0103fc00 Current CPSR : 0x20000013 (Supervisor)
Marking as fixed. Thanks, Norbert.
I had a question regarding this fix. So when I type "monitor test" will whatever "monitor test" returns be displayed on eclipse console? Or is this only to be passed to MIInfo? If it is suppose to be displayed onto the eclipse console than I'm pretty sure the fix does not work. I just wanted to sure as to what exactly it is suppose to do before going on. Hope I didn't waste too much of everyone's time. Mitchell
(In reply to comment #10) Mitchell, the purpose of the fix was to get target stream output records into the MIInfo object which can be processed when the target responds to a (monitor) command. The fix does not intend to change the console behavior. From taking a look at the code I think that the application output should appear in a console, though probably not in the gdb command line console. Alas, I do not have a live example handy and I am not very deeply familiar with the code. Maybe you should post your question on the mailing list if you think there is something wrong with the behavior.
(In reply to comment #11) Norbert, what is supposed to happen in this case? We don't use the "monitor" command and I don't have a test case. Didn't you submit it to solve a problem with your implementation? So, does it work for you or not?
(In reply to comment #12) > (In reply to comment #11) > Norbert, what is supposed to happen in this case? We don't use the "monitor" > command and I don't have a test case. Didn't you submit it to solve a problem > with your implementation? So, does it work for you or not? I am populating a self-made view from the output of the monitor command. - The debug view registers for debug events. (DebugPlugin.addDebugEventListener()). - When a suspend event is fired (DebugEvent.SUSPEND) a worker thread creates a monitor command object (derived from CLICommand) and posts it to the MISession (MISession.postCommand()). - The thread then calls Command.getMIInfo() which makes it wait until the command is finished. - RxThread collects all text which is returned as output in response to the command and puts it into an MIInfo object in the form of out-of-band records (MIOOBRecord). - This is where the bugfix comes in: Only after the fix is the target stream output stored in the MIInfo object and can be processed by the view's worker thread when it returns from MIInfo(). So in short: - Yes, the fix solves a problem, namely to make target stream output available to debug event listeners and - Yes, it works for me. I did not need a console echo of the output and I do not remember (this is now about 6 months past) whether there was a console echo. Alas, my debug view was not used much since then and I do not have a testing scenario handy to see what happens.
Sorry for the confusion. I was under the impression that the fix also enabled the monitor output to eclipse gdb console. But anyways, the fix does what it is suppose to do. Again, sorry for the confusion. Mitchell (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11)
Sorry to awaken this thread again... I am using the "monitor" commands to collect additional information from an embedded target. It is working OK, except that the response is appearing in the console, and I can't disable it. In RxThread#processMIOOBRecord, for objects of class MIConsoleStreamOutput and MILogStreamOutput, isEnableConsole() is checked before writing to the console, but for MITargetStreamOutput it is not and so the output is alwsys written. I can't (and don't want to) change GDB. Any suggestions? Thanks,
(In reply to comment #15) > Sorry to awaken this thread again... I think your request is actually different from what this bug report is about. > embedded target. It is working OK, except that the response is appearing in the > console, and I can't disable it. > but for MITargetStreamOutput it is not and so the output is alwsys written. I agree to your analysis. Bug or feature? that's the question. It could make sense that the target's output stream is written (it is the "standard output" of the debugged application after all) while gdb churn around it is filtered out. If you use the isEnableConsole() method also for the target output stream then you can have either app output plus gdb churn or nothing at all. But I don't have a usecase where this would hurt me. So I suggest you - create a new bugzilla for your request - this bugzilla is related, but not quite the same as yours. - try to start a discussion in the cdt-dev list. If there are no negative replies, why not treat the target output stream like all the others.
This fix creates a memory leak for the duration of the target run. The total memory used is proportional to the print output of the target... see bug 302927
