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

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
>


Back to the top