Re: [cdt-dev] MinGW gdb, Multi-Core Debug
On 4 February 2010 21:29, Dominique Toupin
> 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?
>> -----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?
>> cdt-dev mailing list
> cdt-dev mailing list