Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] MinGW gdb, Multi-Core Debug

Hi James, 

With GDB multi-process/exec you don't have to create different launch, you can attach to many processes running on different core with only one GDB/gdbserver (I think the cores have to be on the same machine), MI also supports this. With multi-core we now have to do stuff in parallel, e.g. in the past your application could fit in one process, now it has to be in many processes running on different cores, I am investigating the below features:
 - view where users can see the cores and what is running on each core, in many cases users will use core affinity to put thread on specific core for execution locality (maybe even memory locality for data). The threads don't move much between cores.
 - user defines what are the process/threads for his application and he want's to attach to all of them;
 - he select one core and he want's to stop it or put a breakpoint on all the threads running on it; or a global breakpoint for the first process or thread hitting the breakpoint;
 - he want's to continue/step for all thread running on that core;
 - he want's to see what are the interaction between process/threads of different cores, e.g. signals so he puts a signal breakpoint;

Pawel also did a multi-context page some time ago (http://wiki.eclipse.org/DSDP/DD/MultiContext) if a few people are interested we could re-start the initiative.



> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: 4-Feb-10 17:37
> To: CDT General developers list.
> Subject: Re: [cdt-dev] MinGW gdb, Multi-Core Debug
> 
> On 4 February 2010 21:29, Dominique Toupin 
> <dominique.toupin@xxxxxxxxxxxx> wrote:
> > Last month the GDB core awareness patches where committed 
> (http://sourceware.org/ml/gdb-patches/2010-01/subjects.html), 
> if you need something special for multi-core debug in DSF-GDB 
> please let us know, we are planning to add multi-core debug 
> to DSF-GDB this year.
> 
> Cool! Just today I've been hacking on a extended-remote 
> target to make it export n-gdb server ports one for each 
> core.  I currently wrap up launching several gdbs with 
> Eclipse using CDI and the core's are shown and managed as 
> part of the launch.
> 
> We're still on GDB 6.8 here, but have a 7 merge in progress. 
> When I get some time I'll take a look at the multi-core 
> support - presumably there are extensions to the gdb server 
> protocol to support multi core debugging? Or is this just for 
> linked in simulators?
> 
> Cheers,
> James
> 
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> >> Sent: 4-Feb-10 13:48
> >> To: CDT General developers list.
> >> Subject: Re: [cdt-dev] MinGW gdb
> >>
> >> > It's too optimistic to believe in the bright future when we
> >> will have
> >> > one universal launch configuration for GDB. Many clients
> >> not only add
> >> > new features but also hide the features they don't support.
> >>
> >> I think this point is key, and likely what Doug was trying 
> to get at:
> >> integrators customise the platform, often provide their 
> own launches 
> >> for their build products, and set defaults for their users.
> >>
> >> In my mind there really are two separate issues:
> >>   - What debug engine CDT should use for debugging GDB by default
> >>   - What APIs are exposed for ISVs to to plug debugging into their 
> >> product.
> >>
> >> As a case in point, we use a GDB based debugger + a custom 
> launch for 
> >> CDI which allows multi-core debugging and GUI for target specific 
> >> options. It's my intention to migrate to DSF, but due to 
> lack of time 
> >> (+ higher priorities) I haven't yet investigated how I can do the 
> >> same things with DSF as I can with CDI.  It'll happen, just not 
> >> today.
> >>
> >> As it stands both sets of API are available and will 
> continue to be 
> >> so for some time.
> >>
> >> I guess this debate really centers on the first point: what the 
> >> default should be for fresh eclipse.org downloads using 
> platform GDB.
> >> In CDT currently, project configurations don't dictate / affect 
> >> launch configurations, as users might see in Visual Studio. In my 
> >> opinion the Eclipse way is more flexible for integrators 
> and perhaps 
> >> as a result more confusing for users.
> >>  I'm not sure what the right answer is here, perhaps integrators 
> >> really should be able to specify a default launch type / debug 
> >> engines for their build configurations, and the default toolchains 
> >> for the various platforms could specify the best default for the 
> >> platform?
> >>
> >> Cheers,
> >> James
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 

Back to the top