Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Multicores programs: pin, clone and coloring

Hi Pawel,

It's more a prototype than a product right now. Our debugger is a multicore debugger, is having MI interface, so we don't use JNI , we just interface to it more-or-less like a GNU GDB does. I said "more or less" since we had to change a little bit the MI parsing to allow communication from and to specific processor. Commands sent to the debugger are dedicated to one processor, we can step one processor while others are runnings.

Right now we just use source view, breakpoint view and debug view. Other you mentioned will need to be tested and adapted to the different kind processors we have in the debug view.

About the double tutorial, I need to discuss with my boss who could attend.
Could you tell me when is your next monthly phone meeting. I've read the last one that occured Jan 3, but don't see when is the next one.


Pawel Piech wrote:
Hi Denis,
I can't resist prying a bit :-) Do you think you could tell us a little more about your product? For example: - What is your debugger back end like, do you integrate with it using JNI or using a sockets or pipes? - Do you use all the features of the UI, including registers, memory, disassembly, and symbol browsing? And of course, like I mentioned before I'd love to know what kinds of issues you have run into integrating your debugger.

I should also let you know that there is going to be a double tutorial <> on implementing a DSF-based debugger at this year's Eclipse Con. If your team is planning to attend, this could be helpful to you. Finally, if you are available, I would like to invite you to join our monthly phone meetings where you can find out about the current and future activity in the project.


Denis PILAT wrote:
Hi Pawel,

I'll give you feedback for sure.
Thanks for the pointer to bug ID 145635, we will find lots of usefull stuff when implementing the pin, clone and coloring policy.

About DSF, it's more than an investigation, we already have a debugger perspective that works (for 90% of its feature) with multicores, we are missing pin, clone and color stuff.

About refactoring ... yes it took a while (fortunately not to me but to the guy who merges all your changes:), but right now we are aligned to DSF version of February 29, and it's nice to see that breakpoint features works better now !
Have you planned other refactoring of big changes ?

Thanks for your answer

Pawel Piech wrote:
Hi Denis,
I have worked on contributing the functionality you mentioned several times over the last couple of years, the latest being the multi-context group in DD <>. That effort is currently on hold we decided with platform group that it was too big a workflow change to consider in 3.4 and I will try to get time to work on it for a future release. Still, it would be very valuable if you could read the proposal that I started and gave your feedback based on your use cases and experience with multi-processor debugging.

What could be more useful to you in the short term is bug 145635 <>, which enables support for multiple instances of debugger views and allows the user to "pin" a view to a current context. Wind River's Eclipse based debugger (where the screen shot below came from) uses a version of this patch to provide improved multi-processor debugging support.


P.S. I'm glad to hear that you're investigating using DSF for your debugger, I hope that the refactoring of APIs hasn't given you too much trouble.

Denis PILAT wrote:
Hello everyone,

We (at ST) are developing a prototype of a GUI, based on Eclipse/DSF,
for debugging C/C++ programs that can address multiple processors.
Some views reflect the state of all processors (like the debug one), but
some others (like the variables, expressions or registers view) can
reflect only one processor at a time.
Debug view lists all processors, each of them will have a particular
color (like in the attached image I got from the Eclipse web site while

I want to change the layout of some views (variables, expressions,
registers) in order to have a kind of coloring policy that will make
distinction between views that are tied to a processor or an other.

Here are my questions:
- For variables, expressions and registers views, is there already a
pin&clone feature that allow to tie a view to a particular context ?
(like it is in the console view with the "Display Selected Console" and
"Pin console" buttons.)
- Is there already a possibility to extend some views so that their
layout could be customizable (like using a specific color for a part of
this view) ?

If you answers is "no and no", how could we envisage to contribute to
such features ?

Thanks for your answers.
Denis PILAT / STMicroelectronics / France

Back to the top