Re: [cdt-dev] Issue with register view for a multicore heterogeneous sys

[Alvaro Sanchez <alvsan09@xxxxxxxxx>]

Upps !, previous e-mail was sent to early.

Here goes the complete response:

1) thread-group-added event

2) register updates per process

3) Inserting break points

I will address 1 and 2 to start, 

1) you have mentioned that you are sending  thread-group-added before sending and MI command.

      You should be able to send thread-group-started event before the thread-started-event(s) for each group, 

      this should make dsf-gdb aware of the groups and associated threads.

2) Register updates per process. 

     There are two bugs related to this which are already available from master although not part of an official release yet.

      Bug 418176, Bug 323552

     Please let me know if you have those as part of your solution.

    

    If you do have them, it would be helpful to see a copy of an MI trace with some comments inserted to know when you were switching processes. 

/Alvaro

On Thu, Feb 6, 2014 at 3:18 PM, Alvaro Sanchez <alvsan09@xxxxxxxxx> wrote:

Hello, 

I see three points here 

1) thread-group-added event

2) register updates per process

3) Inserting break points

I will address 1 and 2 to start, 

1) you have mentioned that you are sending  thread-group-added before sending and MI command.

      You should be able to send thread-group-started event before the thread-started-event(s) for each group, 

      this should make dsf-gdb aware of the groups and associated threads.

2) Register updates per process. 

     There are two bugs related to this which are already available from master although not part of an official release yet.

On Thu, Feb 6, 2014 at 8:39 AM, pvuser pvuser <pvuser@xxxxxxxxx> wrote:

Hi,

Thank you for your answers, were helpful.

We succeeded to have two thread-groups in order to represent our heterogeneous system.

The problem that caused the display of only one of the two thread-groups in the Debug View, was the missing event: =thread-group-added,id=i1.

Adding this event before any MI command is processed, solved the issue.

But still there are issues around –thread-group argument, it doesn't work as expected:

1)      Switching between thread-groups doesn’t update properly the Register View

- we have 2 thread-groups:

- thread-group i1 with two threads: thread 1, thread 2

- thread-group i2 with two threads: thread 3, thread 4

-data-list-register-names --thread-group i1 -> cmd is called only once per debug session

-data-list-register-names --thread-group i2 -> cmd is called only once per debug session. Has different registers then thread-group i1

-data-list-register-values --thread [N] x 0 1 2 3 4 5 6 -> cmd is called to update the values from Register View

- at this point Eclipse should know which thread belongs to which thread-group (-list-thread-groups i1, -list-thread-groups i2) and display the correct registers, but it doesn’t do this

- clicking the process (thread-group) from Debug View, the correct registers names are displayed (only names without value)

- clicking a thread will display always the same registers names (the registers for i1 or i2) depending on the thread [N] from the first invocation of cmd -data-list-register-values –thread [N]

-  If thread [N] belongs to thread-group i1, from now on the registers for i1 will be displayed for all threads (for i1 and i2).

-  If thread [N] belongs to thread-group i2, from now on the registers for i2 will be displayed for all threads (for i1 and i2)

2)       Problem at inserting breakpoints

Because we have a heterogeneous system, we have two different procedures for inserting BPs for the different processors.

So, at the point of inserting a BP, it would we helpful if we knew the thread, but we must know at least the thread-group.

Now we have the following cmd:

-break-insert --thread-group i1 –f <file>:<line>

But, the thread-group is always i1. It doesn’t change if we select thread-group i2 and this is a problem.

 

 

Please can you give us some suggestions, how could we deal with these issues.

Are these known issues that need to be solved or work in progress.

 

Sorry for the long email, but I wanted to explain the issues.

Thank you.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev