RE: [cdt-dev] [DSF] SessionType

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> Sent: Thursday, July 08, 2010 12:28 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] [DSF] SessionType
> 
> Is it me or are we really running into problems with DSF-GDB
> extensibility and customizability? Do we need to take a step back and
> document all the use cases we're trying to accomplish with gdb in the
> many different environments it supports and tweak the architecture to
> make sure we can do them all easily?

During the development of DSF-GDB, DSF itself was modified as we learned
what was needed for a good integration.  The problems that arise now
are specific to DSF-GDB, because we never had to deal with specializing 
DSF-GDB itself.  

With the 'services' approach given by DSF, almost all aspects of DSF-GDB
can easily be changed.  But that requires replacing a DSF-GDB service
with a custom service.  Understandably, people instead want
to re-use as much of DSF-GDB as possible while still customizing it.
Although we don't want to push this re-use too far (at some point
it's normal that since it is not DSF-GDB, it just doesn't use 
some DSF-GDB code), I think we can do some work to make DSF-GDB 
something that is better built to be extended.

Doug is right that it would be good to take a step back and figure out 
which cases should be improved and how to improve them in a sound manner.

I've created (yet another) wiki to allow people to express their
needs for DSF-GDB extensibility.
http://wiki.eclipse.org/CDT/cdt-debug-dsf-gdb-extensibility
It is under the main wiki->Component Documentation-> DSF-GDB extensibility 

Marc
 


> 
> On Thu, Jul 8, 2010 at 12:02 PM, Daniel Jacobowitz 
> <dan@xxxxxxxxxxxxxxxx> wrote:
> > On Thu, Jul 08, 2010 at 11:48:59AM -0400, Marc Khouzam wrote:
> >> > Unfortunately, despite quite some years of experience 
> with gdb, I have
> >> > no idea what LOCAL and REMOTE means.
> >>
> >> REMOTE is when we connect to a gdbserver.
> >> LOCAL is when we use GDB on the host only.
> >
> > I've got to agree with Vladimir.  By labelling these things as LOCAL
> > or REMOTE and making decisions based on the type, it becomes hard to
> > support types that aren't exactly what you envisioned for LOCAL or
> > REMOTE; and that covers a whole lot of ground with GDB and the many
> > ways people use it.
> >
> > Who knows if someone has assumed "LOCAL" means profile output will
> > appear on the local filesystem, or means not to use RSE to launch
> > gdbserver on the target, or means to use run instead of continue?
> >
> >> > - If I do 'target remote | local-something', is this 
> remote or not?
> >>
> >> What does that command do?
> >
> > It runs a program on the host system which speaks the GDB remote
> > serial protocol.  That can talk to a remote device, or even run on a
> > remote system ( e.g. target remote | ssh blah ... ).
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>