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

["Flynn, Stephen" <Stephen.Flynn@xxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Pedro Alves
> Sent: Monday, October 03, 2016 9:11 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Access to Full Gdb Console input
> 
> 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.

When I started to investigate, this was the first thing I looked for.  I agree that this would be the ideal solution.  I just defaulted to how we currently meet this requirement, as well as tried to anticipate possible future needs.

> 
> 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.

Would this require creating an MI equivalent command for info line?

> 
> 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
> >
> 
> _______________________________________________
> 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