Re: [cdt-dev] Access to Full Gdb Console input

[Pedro Alves <pedro@xxxxxxxxxx>]

IMO, it'd be much better to extend GDB somehow and avoid having
to intercept raw input and parse GDB commands, which is GDB's job.

The GDB CLI has a concept of "current source file / last line listed".
Commands that accept source/line as input argument will use the
current source/line if one is not explicitly given.

E.g.:

(gdb) help info line
Core addresses of the code for a source line.
Line can be specified as
  LINENUM, to list around that line in current file,
  FILE:LINENUM, to list around that line in that file,
  FUNCTION, to list around beginning of that function,
  FILE:FUNCTION, to distinguish among like-named static functions.
Default is to describe the last source line that was listed.
                           ^^^^^^^^^^^^^^^^

So I think a =current-source-line-changed or some such new MI event
may be acceptable.

Thanks,
Pedro Alves

On 10/01/2016 06:50 PM, Marc Khouzam wrote:
> No, I had not thought about allowing to extend the new console by
> intercepting the input.  I think it is a good idea. 
> 
> Currently the class GdbTerminalConnector.java simply passes the I/O from
> gdb (non-mi) directly to the view (terminal widget) and vice versa.
> 
> We could add a listener facility that could be registered with, to get
> all input and all output of that console.
> 
> The complexity will probably be to parse that information so it can be
> mapped to actual gdb command. This could be done by the listener
> though.  The important part is to provide the hook to get the info.
> 
> Are you willing to give it a try? It would be reviewed quickly since all
> this code is fresh in our minds :)
> 
> We could even go further and allow to modify the I/O before it goes to
> gdb or is shown to the user, but this is more complicated to do.
> 
> About the breakpoint: did you mean that a breakpoint is created in
> eclipse when you create one in the gdb console?  If so, then yes, that
> is by design where our BreakpointSynchronizer makes sure eclipse knows
> about such console-created breakpoints so it can show them in the editor.
> 
> Feel free to ask for any clarification
> 
> Marc
> 
> ------------------------------------------------------------------------
> *From:* "Flynn, Stephen" <Stephen.Flynn@xxxxxxxx>
> *Sent:* Sep 30, 2016 2:34 PM
> *To:* cdt-dev@xxxxxxxxxxx
> *Subject:* [cdt-dev] Access to Full Gdb Console input
> 
> I have been playing around with the new console and I like it.  We
> currently have an inferior in-house solution that I would love to
> replace with this console.
> 
> One of our requirements is to perform extra actions depending on the
> input.  An example would be opening the source file returned when
> issuing an info line <location> command.  Currently, there is nothing in
> place to allow this.  Nor does this command trigger mi output so there
> is no event to capture.
> 
> Is this something you have considered?
> 
> On a side-note, when creating a breakpoint from the console an extra
> breakpoint is created because the command issues output on the mi stream.
> 
> Stephen Flynn
> Software Engineer 2
> 508-249-9848 / (821) 49848
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>