Martin/John,
I was pondering this a bit as well after Johns email, and my first
reaction was pretty much the same. Yes, a debugger console could use
the same console infrastructure, but the point would be the scripting
and the syntax. Regarding syntax, that could be a very, very long
discussion (religious war?).
It sounded to me as we were discussing connections and such in the last
DSDP meeting in Toronto that it was assumed by everyone that a
connection sequence would have to be a script of some kind since the
actions required are arbitrary for a given system. What is the plan for
the implementation of these scripts?
It would make sense to me that the common debugger commands that John is
asking about could be a pluggable command interpreter that drives some
underlying set of common actions in the debugger. This way we could
have a common command interpreter (and syntax) as a part of DSDP, but
other vendors could also write command interpreters that would be their
own syntax (we have our own of course that we have a lot of customers
using...) So the point is that somewhere there is some overlap.
Aaron
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Oberhuber, Martin
> Sent: Tuesday, April 11, 2006 1:35 AM
> To: Device Debugging developer discussions
> Subject: RE: [dsdp-dd-dev] Console requirements?
>
> Hi John,
>
> By proposing actions like step etc. for a console view, did
> you mean a debugger command prompt?
>
> My understanding of a console was a window into the target's
> or debuggee's input/output.
>
> It might be that part of the technology for a console view
> can be re-used for a debugger command prompt. My feeling,
> however, is that this would be more related to scripting
> (i.e. scripting debugger actions that are otherwise available
> in the GUI).
>
> The script commands would then be executed from a generic
> script interpreter / command prompt. So, your suggestion
> would boil down to creating a scriptable DOM for debugger actions.
>
> Does this make sense?
>
> Cheers,
> Martin
> --
> Martin Oberhuber - WindRiver, Austria
> +43(662)457915-85
>
>
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> > Sent: Monday, April 10, 2006 8:28 PM
> > To: Device Debugging developer discussions
> > Subject: RE: [dsdp-dd-dev] Console requirements?
> >
> > Sorry for chiming in so late on this.
> >
> > So besides the mechanics of a console window, including the desired
> > ability to connect one to some sort of processing engine of
> arbitrary
> > nature, we should consider whether we'd want to create a processing
> > engine that deals with the common debugger actions.
> >
> > I.e., while Freescale might want to introduce a console to let the
> > user drive a CodeWarrior debug session in a proprietary
> way, I would
> > think it might be desirable to have a console that allows a user to
> > drive a debug session in a common way. There's certainly a
> good amount
> > of commonality across debuggers in general: step in, step
> over, step
> > out, run, suspend, terminate, stackcrawl, show/modify locals, etc,
> > etc...
> >
> > I can't tell if this is already part of what's being
> considered, or if
> > anyone sees any value in this. But it seems that as Eclipse based
> > solutions proliferate in the embedded market, the ability to drive
> > basic debugging operations from a console in a way that's
> consistent
> > across solutions/vendors might be useful.
> >
> > John
> >
> > At 11:59 AM 4/10/2006, Spear, Aaron wrote:
> > >Ewe,
> > >
> > >We just finished talking about it a little bit on the TM
> > phone call. To
> > >summarize:
> > >
> > > >From the comments on these feature requests/bug reports,
> > it appears that
> > >Darin and others would be open to having us submit whatever
> > changes we
> > >need to the platform (as stated, they don't have the
> bandwidth to do
> > >more at the moment) As such, it sounds like we ought to
> > figure out our
> > >requirements, and then after a bit of design and review,
> > copy-and-paste
> > >what we need to live somewhere in the DSDP sources for
> now, and then
> > >submit whatever makes sense back (at least any framework
> > changes). It
> > >sounds like the pluggable terminal emulations should be
> used by the
> > >existing RSE "shell" component as well as the process console.
> > >
> > >I must disclose that I have not yet studied the current console
> > >architecture. It sounds as though you have. I am
> presuming that you
> > >are the one that wrote Wind's current telnet implementation
> > which both
> > >Doug and Martin have talked about being a possible
> > contribution. How
> > >do you think we should go about discussing the refactoring
> > that needs to
> > >happen in the framework as well as the design we want to
> > have for this
> > >stuff moving forward? You mentioned a few items below. I
> > have no idea
> > >what the process should be as far as the platform changes
> > goes. Perhaps
> > >if the changes to simply enable what we want are not too
> radical they
> > >can be done before 3.2 is complete if we do the implementation and
> > >submit it? (no idea if that is a ridiculous expectation or not)
> > >
> > >regards,
> > >Aaron
> > >
> > >-----Original Message-----
> > >From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > >[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Stieber, Uwe
> > >Sent: Saturday, April 08, 2006 3:11 AM
> > >To: Device Debugging developer discussions; Target
> > Management developer
> > >discussions
> > >Subject: RE: [dsdp-dd-dev] Console requirements?
> > >
> > >Hi Aaron,
> > >you may want to refer to the bugzilla entries
> > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=36669 and
> > >https://bugs.eclipse.org/bugs/show_bug.cgi?id=111186. They
> both deal
> > >with Consoles and need to take into account if modifying
> the platform
> > >console service.
> > >
> > >Basically an improved console should allow easy "connectivity" to
> > >whatever. First hand, we look mainly for getting the
> > currently existing
> > >implementation of the ProcessConsole splitted into an public
> > >ProcessConsole (not tight together with launch configurations) and
> > >possible still internal DebugProcessConsole (tight together
> > with launch
> > >configurations as the current implementation is, no change
> to current
> > >users/clients). This is basically similar to what you
> pointed out in
> > >your second point besides the console infrastructure should not be
> > >limited to debuggee processes only.
> > >
> > >Additional, the consoles should have an contributable font
> and colour
> > >provider which allows to change fonts/colours for matching
> > parts of the
> > >document. The current implementation of the platform console
> > >infrastructure requires to replace the whole
> > >IDocument/IDocumentPartitioner implementation of the console
> > which is an
> > >overkill for the basic requirement to get all three streams
> > of a process
> > >very easely connected to an console and to have influence on the
> > >presentation by in example simple regex matcher.
> > >
> > >Best regards,
> > >
> > >--
> > >Uwe Stieber
> > >Senior Software Engineer
> > >Engineering - Wind River Gmbh - Austria
> > >
> > >
> > > > -----Original Message-----
> > > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Spear, Aaron
> > > > Sent: Friday, April 07, 2006 5:54 PM
> > > > To: Device Debugging developer discussions; Target Management
> > > > developer discussions
> > > > Subject: [dsdp-dd-dev] Console requirements?
> > > >
> > > > Hello All,
> > > >
> > > > I wanted to kick off a thread to solicit some
> > requirements/thoughts
> > > > for consoles in the brave new DSDP world. I will throw a
> > few out that
> > >
> > > > I can
> > > > see:
> > > >
> > > > -Pluggable/Selectable terminal emulations (plain text, vt-100,
> > > > vt-220,...). We ought to have stock ones like those
> > mentioned, but
> > > > there should be an extension point so others can
> > contribute something
> > > > completely specific if they want.
> > > >
> > > > -Pluggable connectivity to the other side. The simple
> > use case is a
> > > > replacement/augmentation of the existing Eclipse
> console, one that
> > > > does stdio with the debugged process. I think that we
> > will want to
> > > > reuse the same component elsewhere though, e.g. a
> > terminal opened on a
> > >
> > > > socket from the RSE or something.
> > > >
> > > > I don't know what exactly we will do with this little
> > sub-project. It
> > >
> > > > seems to me that it should probably be pushed into the
> > platform (at
> > > > least the framework changes for
> > > > consoles) and then perhaps we have specific terminal
> > emulations that
> > > > exist in DSDP?
> > > >
> > > > cheers,
> > > > Aaron
> > > >
> > > > --
> > > > Aaron Spear
> > > > Debug Tools Architect/Staff Engineer Mentor Graphics
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > dsdp-dd-dev mailing list
> > > > dsdp-dd-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > >
> > >_______________________________________________
> > >dsdp-dd-dev mailing list
> > >dsdp-dd-dev@xxxxxxxxxxx
> > >https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > >_______________________________________________
> > >dsdp-dd-dev mailing list
> > >dsdp-dd-dev@xxxxxxxxxxx
> > >https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> >
> > _______________________________________________
> > dsdp-dd-dev mailing list
> > dsdp-dd-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> >
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
