[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cdt-dev] [DSF] SessionType
- From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
- Date: Thu, 8 Jul 2010 12:50:42 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: AcsevPIHk4NVqMgcRvqIcdo04/c5CwAAFW6w
- Thread-topic: [cdt-dev] [DSF] SessionType
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: Thursday, July 08, 2010 12:42 PM
> To: CDT General developers list.; CDT General developers list.
> Subject: Re: [cdt-dev] [DSF] SessionType
> One thing I've observed is that there seems to be a hesitancy to bump
> the major version of DSF and DSF-GDB. With a noticeable increase in
> adopters, I suspect a lot of holes and bad assumptions are going to
> surface. Attempting to tackle these issues without breaking backward
> compatibility is going to yield some pretty ugly results, IMO. I
> think we should be willing to accept a major version change in Indigo
> and start opening the table to well architected solutions to these
> problems rather than convoluted ones which maintain backwards
> compatibilities but hurt DSF in the long run.
That is a good point.
But let's not up the version for a specific solution for one
particular case. But if we have a "well architected solution"
that will help many integrators, it does seem like it is worth
the change in version.
> At 11:28 AM 7/8/2010, Doug Schaefer wrote:
> >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?
> >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 mailing list