[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
