[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] StandAlone CDT debugger (was: Debugging native apps)
|
Two of the more common use cases that we do have today for our (non-Eclipse) Code Compose Studio product are:
(1) Connect to target, browse to, load and run target executable (perhaps debug)
(2) (Program in Flash memory) Connect to target, browse to executable/symbol file, load symbols, run target executable (perhaps debug)
Both are very valid with or without the presence of a project or source files. This is not unique to our product as I have often used windbg or DevStudio to simply load up and debug an application without the sources when I come across a crash.
Like Chris says, currently this usage pattern is very clumsy in Eclipse in general with the requirement being that the resources have to be in (somehow) in the workspace. I'm not yet sure how we're going to address this but our users are definitely going to come across this when we start enabling CCE for more complex processors which will have much more complex projects that are built in custom environments.,
Anyway I suspect that this may be a very common usage pattern for embedded tool vendors - I hope a number of us can get together at EclipseCon and discuss this and other related topics.
Martin
--
----
Martin Imrisek <mimrisek@xxxxxx>
Software Systems Designer
Software Development Systems
Texas Instruments
416-340-2096
-----Original Message-----
From: cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-admin@xxxxxxxxxxx] On Behalf Of Recoskie, Chris
Sent: January 6, 2005 1:05 PM
To: cdt-debug-dev@xxxxxxxxxxx
Subject: RE: [cdt-debug-dev] StandAlone CDT debugger (was: Debugging native apps)
I have to agree with some of the principles that Øyvind is putting forward, even if not all of his suggestions apply to TI's needs in particular at this moment. It's not all just about speed. We also run into the simplicity issue, just not in the same way as Øyvind.
We have definite use in general for perspectives, etc. However, our current users are developing C and assembly programs for the MSP430, and if you start showing them things like the JDT, PDE, GNU toolchains, etc., they get very confused. They have a hard time finding what they want to do, or end up thinking they can do things that they really can't ("What do you mean I can't create a Java program for the MSP430? What is CygWin? What do you mean I can't use GNU tools when they're shown right there as a new project option???"). Right now we actually strip out the JDT, PDE, and the GNU toolchain definitions for our product to avoid all these headaches.
Right now for an embedded developer to use Eclipse + CDT out of the box untouched you really have to be an Eclipse + CDT + GDB expert to be able to easily figure out what you're doing. Many of our users barely know what GDB is let alone how to configure it properly for remote debugging. Admittedly though, a large part of the difficulty our users encounter has to do with the general usability level of Eclipse and that's a whole other kettle of fish :-P
Anyway... back to Øyvind's idea. Right now we don't have a pressing need for a debugger-only flavour of CDT, but I can forsee some of our users wanting this out of our Eclipse based products in the future. We have users of Code Composer Studio (our non-Eclipse product) that do all of their building remotely under ClearCase dynamic views on an shared Solaris box, do all their editing using vi or emacs on the same Solaris box, and have a PC sitting at their desk which they do their debugging on. All they care about when it comes to our tools is having a graphical debugger on the PC. All they want to have to do is point the debugger at the executable file, and away they go. They don't mind having to configure their hardware setup for the debugger once, or possibly setting up a few other global options like "halt at main", but after that they don't want any nonsense about projects or telling the debugger where their source files are (since this is contained already in the relative path info stored in the debug information), or anything else. Literally they want to click Debug, browse to an executable file, and that's it; their project is loaded on their hardware and run on the remote target.
Personally for us (i.e. TI) in particular I don't think the debugger-only issue is a super critical issue... it's more of a "nice to have someday" type of thing in our minds, and we will always have a need for a full-fledged IDE. It is however a valid usage model that many people will want to pursue.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
> -----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-
> admin@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
> Sent: Thursday, January 06, 2005 12:23 PM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] StandAlone CDT debugger (was: Debugging
> native
> apps)
>
> > Problems:
> > - CDT/Debug lies on top of the Eclipse/Debug platform, which will
> > pull
> in JFace, Eclipse/UI,
> > Workbench and all ... CDT/Debug depends also on CDT/{Core, UI}(use
> > of
> the AST parser and the binary parser).
> > So it is still "heavy" ...
>
> I wasn't referring to performance when I say "strip down Eclipse".
>
> I want to reduce the number of concepts that are introduced "just to
> do debugging".
>
> There is e.g. no need to explain the user what an "Eclipse Perspective"
> is. Ditto for "Eclipse Project".
>
> > - Glossing over the need to create a workspace(IFile and all) on the
> fly.
>
> Trivial once solved. :-)
>
> > Maybe I'm wrong, but I always have the impression that if Eclipse
> > could
> start within 2 seconds
> > we would not have this exchange 8-).
>
> I don't think so.
>
> If I believed that, I wouldn't have suggested a standalone debugger in
> the first place.
>
> > Visual Studio can start within 2 seconds and I do not see/hear any
> requests for "stand-alone" versions.
>
> Not on my machine. It has a mere 3GHz HT 768MByte RAM, so thats
> understandable... :-)
>
> > I have to agree about improving the ease of use, whether with better
> support autoconf/automake or
> > better/simpler integration etc ..
> >
> > Meanwhile, users can:
> > - create a project(std make), change the default location to point
> > to
> the executable and .. debug.
> > - or using an existing project, use linked folder/file
>
> There is no "meanwhile" for Eclipse here.
>
> It is Insight *until* this is in place.
>
> We are talking about users whose *primary* working environment is bash.
>
> Eclipse will never make bash obsolete. Just like the GDB console,
> Eclipse should embrace bash.
>
> Make Eclipse available to bash users on their own terms. Ditto for
> "Eclipse Projects" vs. existing makefile systems.
>
> Eclipse is the detour. It should introduce the minimum number of
> concepts and additional reading to get the job done.
>
> "They can put men on the moon, but they can't launch the CDT debugger
> from bash" :-)
>
> Ditto for standalone Eclipse CVS GUI btw.
>
> --
> Øyvind Harboe
> http://www.zylin.com
>
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
