Community
Participate
Working Groups
"GDB Hardware Debugging" launch configuration type will not create an output console for running target. For hw gdbserver agents supporting semi-hosting, gdb can report programs console output as "target-stream-output". =========================================== The easiest way to trigger a "target-stream-output" MI record is to issue "monitor help" gdb CLI command. Steps to reproduce in the lack of a HW target with semi-hosting support: - Create a "GDB Hardware Debugging" LC. * in "Debugger" tab, uncheck "Use remote target". * in "Startup" tab, uncheck the following "Reset and Delay","Halt", "Load Image", "Load Symbols" * in "Startup" tab, in initialization commands edit field set the following commands: target extended-remote localhost:10000 file {path_to_program} set remote exec-file {path_to_program} * in "Startup" tab, set "main" as "Set breakpoint at:" symbol. * in "Startup" tab, in "Run Commands" edit field write "run" - From a terminal execute "gdbserver --multi :10000" - Start debug session - From eclipse gdb console, issue "monitor help"; Nothing is displayed. - In gdb trace console notice the MI records: @"The following monitor commands are supported:\n" @" set debug <0|1>\n" .... ===========================================
GDBJtafDSFFinalLaunchSequence does not inherit the standard "stepNewProcess" execution step. Instead the launch sequence can be extended with its own "stepCreateConsole" that would create an MIInferiorProcess that would link GDB-MI target stream to eclipse process console. I will attach a patch with this enhancement
Proposed patch https://git.eclipse.org/r/28575
So the idea is that we will create a new console for the inferior program but that the console will only be used to print the target-stream? Does this fit with the different ways a hardware launch can be used? For example, in the setup you give in comment 0, inferior output goes to the gdbserver terminal while target-stream output goes to this new console. Is this what will/should happen in all cases? If so, maybe the labelling of the console should reflect that. Also, I'm a bit concerned about using the MIInferiorProcess class in this case when it does not seem to actually be properly matched to a real inferior. But maybe I'm not understanding the hardware launch properly... My impression is that we will be creating an MIInferiorProcess all the time although I'm not sure we always know what that inferior is, or if there is one. Could you help me understand a bit better that part?
As far as I understand, with the patch a monitor commands is issued from the gdb console and the result can be viewed in the program console. Is this correct?
(In reply to Mikhail Khodjaiants from comment #4) > As far as I understand, with the patch a monitor commands is issued from the > gdb console and the result can be viewed in the program console. Is this > correct? That is also what I understood. (In reply to Marc Khouzam from comment #3) > Also, I'm a bit concerned about using the MIInferiorProcess class in this > case when it does not seem to actually be properly matched to a real > inferior. I now think that our handling of target-stream output is broken in general. What is that output really meant to come from? Is it from the single remote target or from the inferior (of which we can have many)? I think it is from the remote target. If that is the case it should not be handled by MIInferiorProcess. Before support for multi-process, we could get away with using MIInferiorProcess for the target-stream, but now I think it should be handled by some class that has only one instance per session (per target actually, but for now we can only have one target). This is not a problem currently since target-stream only comes from a remote session, and we don't have consoles when doing a remote session. The changed proposed for GDB Hardware debugging would bring this issue to the forefront. So, I suggest moving the logic that handles target-stream output out of MIInferiorProcess. Does that make sense to you guys?
(In reply to Marc Khouzam from comment #5) > (In reply to Mikhail Khodjaiants from comment #4) > > As far as I understand, with the patch a monitor commands is issued from the > > gdb console and the result can be viewed in the program console. Is this > > correct? > > That is also what I understood. > This is not very convenient. Switching back and forth from one console to another to enter commands and view their results is very confusing. We already have complains. In our case the target stream goes to the application console which gets activated. Then the user tries to type the next command in it and the command is not accepted because of the wrong console. > (In reply to Marc Khouzam from comment #3) > > > Also, I'm a bit concerned about using the MIInferiorProcess class in this > > case when it does not seem to actually be properly matched to a real > > inferior. > > I now think that our handling of target-stream output is broken in general. > What is that output really meant to come from? Is it from the single remote > target or from the inferior (of which we can have many)? I think it is from > the remote target. If that is the case it should not be handled by > MIInferiorProcess. Before support for multi-process, we could get away with > using MIInferiorProcess for the target-stream, but now I think it should be > handled by some class that has only one instance per session (per target > actually, but for now we can only have one target). > > This is not a problem currently since target-stream only comes from a remote > session, and we don't have consoles when doing a remote session. The > changed proposed for GDB Hardware debugging would bring this issue to the > forefront. > > So, I suggest moving the logic that handles target-stream output out of > MIInferiorProcess. Does that make sense to you guys? It seems that gdb sends the output of monitor commands to the same stream as the program output (@). At least that's what I see with our sessions. In this case there no way to differentiate between the program's output and the monitor command's output.
(In reply to Mikhail Khodjaiants from comment #6) > This is not very convenient. Switching back and forth from one console to > another to enter commands and view their results is very confusing. We > already have complains. In our case the target stream goes to the > application console which gets activated. Then the user tries to type the > next command in it and the command is not accepted because of the wrong > console. Good point. That is not user friendly. > It seems that gdb sends the output of monitor commands to the same stream as > the program output (@). At least that's what I see with our sessions. In > this case there no way to differentiate between the program's output and the > monitor command's output. I never see these @ signs in my testing. How do you see them when dealing with program output? Can you give the steps?
(In reply to Marc Khouzam from comment #7) > I never see these @ signs in my testing. How do you see them when dealing > with program output? Can you give the steps? Hmm, I can't see them with the main CDT configuration types. I guess, gdb doesn't use the target stream for local applications and for gdbserver sessions I don't see it either. I get the mixed monitor/program output when connecting to QEMU or using JTAG connections.
(In reply to Mikhail Khodjaiants from comment #8) > (In reply to Marc Khouzam from comment #7) > > I never see these @ signs in my testing. How do you see them when dealing > > with program output? Can you give the steps? > > Hmm, I can't see them with the main CDT configuration types. I guess, gdb > doesn't use the target stream for local applications and for gdbserver > sessions I don't see it either. I believe GDB will only use that stream for remote targets (e.g., gdbserver) and currently, we don't setup a console for that output in CDT. > I get the mixed monitor/program output when connecting to QEMU or using JTAG > connections. So the inferior outputs using @ in those cases? I assume there couldn't be multiple inferiors in those situations, or could there? I also assume you are not using -inferior-tty-set in those cases.
(In reply to Marc Khouzam from comment #9) > > I get the mixed monitor/program output when connecting to QEMU or using JTAG > > connections. > > So the inferior outputs using @ in those cases? Yes and there is no way to separate the output from monitor commands from the program's output. > I assume there couldn't be multiple inferiors in those situations, or could > there? I don't know how it works with multiple inferiors. Those targets don't support multi-process debugging. > I also assume you are not using -inferior-tty-set in those cases. No, I am not. I suspect it may work for some cases but not for all.
(In reply to Mikhail Khodjaiants from comment #10) > (In reply to Marc Khouzam from comment #9) > > > I get the mixed monitor/program output when connecting to QEMU or using JTAG > > > connections. > > > > So the inferior outputs using @ in those cases? > > Yes and there is no way to separate the output from monitor commands from > the program's output. So either we must send all that output to a new inferior console as proposed by Teodor, or we must send it all to the gdb console if we are to keep the answer of a monitor command in the console as where it was typed. Unless we can use -inferior-tty-set to separate the inferior's output from the target output but as Mikhail says, it may not work for all situations. > > I assume there couldn't be multiple inferiors in those situations, or could > there? > > I don't know how it works with multiple inferiors. Those targets don't > support multi-process debugging. Ok, so we don't have to worry about that.
(In reply to Mikhail Khodjaiants from comment #4) > As far as I understand, with the patch a monitor commands is issued from the > gdb console and the result can be viewed in the program console. Is this > correct? The monitor example is an artificial example to easily get a sample of "@" MI packet. Though indeed this is an unpleasant side effect that should be addressed in GDB, or maybe as a solution to Bug 208950. The use-case attempted to address is semi-hosting with JTAG connection. In this context GDB does support semihosting only in all-stop mode (due to RSP protocol limitation) and only for one process inferior. It is still possible to do mult-core JTAG debugging, but only as an SMP session (multiply threads per inferior), thus having only one console. A similar use-case in the realm of on-host debugging is Windows OS host support (at least with cygwin gdb). On Windows OS, unlike tty redirection on Linux, eclipse is expecting target output stream intermixed with GDB-MI (though not in a standard MI way with "@" prefix).
(In reply to Marc Khouzam from comment #11) > (In reply to Mikhail Khodjaiants from comment #10) > > (In reply to Marc Khouzam from comment #9) > > > > I get the mixed monitor/program output when connecting to QEMU or using JTAG > > > > connections. > > > > > > So the inferior outputs using @ in those cases? > > > > Yes and there is no way to separate the output from monitor commands from > > the program's output. > > So either we must send all that output to a new inferior console as proposed > by Teodor, or we must send it all to the gdb console if we are to keep the > answer of a monitor command in the console as where it was typed. It could be an acceptable solution for GDB HW debugging. It would be a similar look-and-feel with gdb command-line experience, where users are seeing GDB commands intermixed with application std-out. The patch was intended to bring a similar look-and-feel with the eclipse application debugging with regards to having a separate console per process. But that it is not in the top priority. > Unless we can use -inferior-tty-set to separate the inferior's output from > the target output but as Mikhail says, it may not work for all situations. > Unfortunately -inferior-tty-set does not work for remote targets in gdb (GDB JTAG debugging being a subclass)
I've made different attempts to provide an unified console view that would handle both target and gdb consoles as one console. The conclusion that this will bring more confusion then ever due to the current nature of gdb is expecting to receive target input. There's no mi command explicitly to send to gdb some characters as input to target program, thus depending on target running state some commands will be either interpreted as a gdb command or as program input. To complicate matters as well AbstractCLIProcess.CLIOutputStream is wrapping user input into "-interpreter-exec console" mi command, thus target program will receive totally different input. As a result I would go with the solution to have a separate console for program as the only option. Together with a fix for Bug 208950 that will handle "monitor" command. After fixing Bug 208950 I will revisit the patch, as the result of monitor command should not end into inferior console. Marc, Mikhail are you ok with this?
(In reply to Teodor Madan from comment #14) > I've made different attempts to provide an unified console view that would > handle both target and gdb consoles as one console. The conclusion that this > will bring more confusion then ever due to the current nature of gdb is > expecting to receive target input. > There's no mi command explicitly to send to gdb some characters as input to > target program, thus depending on target running state some commands will be > either interpreted as a gdb command or as program input. We must be talking about non-stop here, no? GDB input vs inferior input was not a problem before because in all-stop, it was clear which one was which: either the inferior was running and gdb was not accepting input, or the inferior was stopped and it was not accepting input. Are you therefore using non-stop to hit this problem? > As a result I would go with the solution to have a separate console for > program as the only option. Together with a fix for Bug 208950 that will > handle "monitor" command. I'm hesitant about this as it only addresses the monitor command. Couldn't there be other commands that would trigger some target output from gdb itself? I am under the impression that until GDB can make the difference between GDB-target output and inferior-target output, we would have to stick everything into the same console. However, if you tried that and it was not user-friendly, we could be forced to look at this less-general solution as the only viable solution at this time. Let's first see if this is because of non-stop and go from there.
(In reply to Marc Khouzam from comment #15) > We must be talking about non-stop here, no? Remote inferior console IO is supported *only* in all-stop mode. The capabilities are defined by gdb "Remote Serial Protocol" and current (gdb 7.8) specs do not cover non-stop. Console IO is covered by "O" packet: "‘O XX…’ .... This can happen at any time while the program is running .... This reply is not permitted in non-stop mode." Also another way is through https://sourceware.org/gdb/onlinedocs/gdb/File_002dI_002fO-Overview.html#File_002dI_002fO-Overview > GDB input vs inferior input was not a problem before because in all-stop, it > was clear which one was which: either the inferior was running and gdb was > not accepting input, or the inferior was stopped and it was not accepting > input. > I am hesitant to introduce inferior run-control state logic in the way input from user is interpreted and passed through to GDB input stream. i.e. if thread is suspended wrap user input into "--interpreter-exec console", else if thread is running then pass user input to GDB stream as it is. But I could give another try. > > > As a result I would go with the solution to have a separate console for > > program as the only option. Together with a fix for Bug 208950 that will > > handle "monitor" command. > > I'm hesitant about this as it only addresses the monitor command. Couldn't > there be other commands that would trigger some target output from gdb > itself? I am not aware of any standard command that would behave this way, though we could design extensible the check in Bug 208950 to override how MIOOBRecords associated with a command is handled. > I am under the impression that until GDB can make the difference between > GDB-target output and inferior-target output, we would have to stick > everything into the same console. The behavior is good as long as only inferior-target output is streamed, i.e. not inferior-target input. > Let's first see if this is because of non-stop and go from there. The problem exists only for all-stop as non-stop mode does not have this feature.
(In reply to Teodor Madan from comment #16) > > I'm hesitant about this as it only addresses the monitor command. Couldn't > > there be other commands that would trigger some target output from gdb > > itself? > I am not aware of any standard command that would behave this way, though we > could design extensible the check in Bug 208950 to override how > MIOOBRecords associated with a command is handled. > > > I am under the impression that until GDB can make the difference between > > GDB-target output and inferior-target output, we would have to stick > > everything into the same console. > The behavior is good as long as only inferior-target output is streamed, > i.e. not inferior-target input. Do we really have to handle inferior-target input when dealing with hardware debugging? If I think of a session connecting to a gdbserver, the console of the inferior is not handled by Eclipse but by whatever started the gdbserver/inferior. On a hardware target, once wonders how there could be inferior output going to GDB; why is that output not handled in the same way as when there is no debugging happening. What was suggested to me is that the inferior output is lost/ignored when GDB is not around, but when it is, it is sent through the target-stream; a type of debug-printouts. But do we have to worry about this for input? If the program waits for input, what happens when there is no GDB? Where does that input come from? > > GDB input vs inferior input was not a problem before because in all-stop, it > > was clear which one was which: either the inferior was running and gdb was > > not accepting input, or the inferior was stopped and it was not accepting > > input. > > > I am hesitant to introduce inferior run-control state logic in the way input > from user is interpreted and passed through to GDB input stream. i.e. if > thread is suspended wrap user input into "--interpreter-exec console", else > if thread is running then pass user input to GDB stream as it is. > > But I could give another try. I don't like this either. Sometimes the user will type a gdb command in the gdb console even if the inferior is running and not accepting input. That command is buffered by GDB and consumed when it gets control back. Instead we could could use your original solution of having two consoles but direct the output to the correct console based on the run-control state of the inferior? If the inferior is running we print the @ stream to the inferior console, and if it is not, we print it to the gdb console. That could be a more general solution to Bug 208950.
This bug was assigned and targeted at a now released milestone. As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and marked the bug as resolved.
I've tried to give monitor help from debugger console view and I can see the original reported issue is still there (didn't get the response in the same view-Debugger console). Where as when I tried "i r", I got the response in debugger console view itself. I felt the issue is still open. @jonah@kichwacoders.com what do you think?
