Re: [cdt-dev] Multicore Visualizer on 576 cores

[Xavier Raynaud <xavier.raynaud@xxxxxxxxx>]

Hi Marc,

[...]

>> Lessons learned:
>> (1) When gdb connects to this platform, he ask each core/thread individually
>> for his state. It's a bit slow...

> Are you talking about GDB itself, or of CDT?  I'm wondering if you are describing
> a delay when GDB connects to the target and another delay when CDT requests
> information from GDB, or if there is one single delay from CDT to GDB?

It's not gdb itself. From command line, it's very fast. 



>> (2) When visualizer connects, he does the same things: so we have to wait
>> twice longer.

> If the visualizer uses the DSF services, the caching mechanism should kick in
> and there should be no need to go back to GDB for the information that was
> already fetched.

I've seen that. I started to use the caching mechanism, and I gain a few time.
Note: I didn't found any documentation about DSF caching mechanism. Is it documented somewhere ? 



>> Our gdb is able to return the state of the whole system with a single "info
>> thread" command.
>> I was able to use this feature to populate the multicore visualizer view faster
>> (much faster).
>> 
>> However, I do not know how to use the feature to populate the standard
>> debug view. Any hints ?

> The debug view gets its information using the DSF services, mostly the IProcesses
> service.  Overriding that one to use an enhanced 'info threads' is how you would
> improve this.

I think you hit the point. My implementation of IProcesses service is not optimal.
I will investigate further on this service.


Many thanks,
Xavier