[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] Re:Re: Using CDT as avr-gdb frontent for AVR target platforms
|
I will answer which ones I can...
1. In general, any port of GDB which was created from the original sources on gnu.org will have support for the MI interfaces. In order to get the "mi1" interface that CDT wants, you will need GDB 5.2 or higher. I am not familiar with Øyvind's particular GDB port but I assume it fulfils this requirement.
2. I will leave for Øyvind to answer since it's his patch :-)
3. The easiest way to find out what CDT is doing with the debugger is to run CDT under a runtime workbench debug session under Eclipse and turn on trace for the org.eclipse.cdt.debug.mi.core plug-in. You do this via the "Tracing" tab under your debug configuration for the runtime workbench. This will log all of the data that is sent back and forth to and from GDB to the console window of your Eclipse debugger.
Now... Soapbox time again! :-)
Re: your PS, I definitely agree that for most users the simple solution is fine. However, the amount that fall into the "other" category is still larger than you think, and more important than you think.
For a lot of the companies contributing to the CDT such as us at TI, those customers are our bread and butter. I can't say no to thousands of both existing and potential customers that need a solution which solves the kind of problems I described.
I especially can't say no when they are buying literally hundreds of millions (probably even billions over the course of more than a year) of dollars worth of chips from us. Money talks :-)
Anyway, to clarify my original point from a previous post, I don't think we want either space to suffer. I wouldn't advocate pushing my RT/MP debug at the expense of the quality of the support for the GNU toolchain. What I'm saying is that it's important to eventually do both, and do them reasonably well.
I'm not advocating just enabling the debug paradigms that I think meet my needs either though. I think we should enable and encourage any kind of debugging we can. As a for instance, I would love to see the day where I could stop using MS Dev Studio and use CDT to develop and debug MFC/Win32 applications. Or hell, Cocoa programs for the Mac (although I think they're written in Objective C as opposed to regular C, aren't they?). The possibilities are endless...
As a cheesy actor once said... "If you build it, they will come..."
___________________________________________
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 Björn Haase
> Sent: Thursday, May 20, 2004 5:24 PM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] Re:Re: Using CDT as avr-gdb frontent for AVR
> target platforms
>
> Thanks for your answers,
>
> I will have a look at the way that Øyvind Harboe used to deal with his arm
> target during the next days. (I expect to need to spend some time on more
> *basic* problems in order to understand more clearly the mechanism of how
> CDT launches the debugger. I so far have avoided to look at the CDT
> sources.)
>
> In order to understand more clearly please allow me to ask three
> additional
> (possibly stupid) questions:
>
> 1.) Concerning MI interface: I understood that in case that you take the
> gdb
> sources from the gnu site and compile them for your target platform, you
> can
> assume that the MI interface support already is included.? At least I
> understood that Øyvind Harboe's arm-gdb already had MI-support. Is this
> correct? (I would like to make sure that on my GDB and JTAG-Tool side all
> the requirements are met before starting to deal with CDT internals).
>
> 2.) Concerning the patches of Øyvind Harboe: I understood that your patch
> basically gives the user the possibility to use the gdb command line in
> order to use its flexibility to issue instructions that usually are not
> necessary. I.e. commands that are not required unless you are dealing with
> remote target systems or other non-standard debugging tasks. Did I
> understand correctly ?
>
> 3.) For debugging purposes: Is there an easy way to find out what CDT does
> when it is trying to establish the connection to the debugger? E.g. is it
> possible to find out which other tools are launched and what kind of
> communication CDT is having with them?
>
>
> Yours,
>
> Björn Haase
>
> P.S.:
> Concerning the more *philosophical* questions concerning the requirements
> for the power and flexibility of the CDT debugging interface: My personal
> impression is that a "simple" solution supporting most of the GDB
> capabilities and a single-processor target will probably meet the
> requirements of the vast majority of possible users.
>
> -----Ursprüngliche Nachricht-----
> Von: alain@xxxxxxx [mailto:alain@xxxxxxx]
> Gesendet: Mittwoch, 19. Mai 2004 21:41
> An: cdt-debug-dev@xxxxxxxxxxx
> Cc: Bjoern.M.Haase@xxxxxx
> Betreff: Re: [cdt-debug-dev] Re: Using CDT as avr-gdb frontent for AVR
> target platforms
>
>
> >
> > > 4.) Does anybody now of somebody who has tried (or better:
> succeeded)
> =
> > > to use CDT for AVR targets?
> >
> > Not AVR targets, but I've used them against arm-elf targets.
> >
> > I've posted two patches, which should allow you to debug the AVR target
> > easily.
> >
> > http://dev.eclipse.org/mhonarc/lists/cdt-patch/msg02306.html
>
> This one will break things. Needs more evaluation.
>
> > http://dev.eclipse.org/mhonarc/lists/cdt-patch/msg02298.html
> >
>
> This is still subject to heavy debate on this side of the pound.
> About the "right" way to handle all of those targets cleanly
> whithout bloating the CDT. The first approach, provide your
> launch and entry point seems to be to much for the casual
> users "who just want to run gdb on there XXX cpu".
>
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
