[cdt-dev] Different address space for each debugged thread

[Tomas Martinec <fyzmat@xxxxxxxxx>]

Hello,

I am writing an Eclipse plugin for debugging my system (MIPS based)
virtual machine. The VM can have more processors and a straightforward
way to represent the processors in CDT is to have them as threads.
Basically that works fine, but I observed a few troubles:

1 - Eclipse seems to assume that all the threads have the same address
space, which is not true in my scenario. The way of addressing the
memory of a processor is determined by some content of registers and
the TLB. Therefore the content of the memory shown in Eclipse is
dependent on the active thread in the debugger. CDT caches the memory
obtained from GDB and that makes part of troubles. For example, if the
programmer switches the threads in the debugger then the memory should
be reloaded from the VM, but it is not because of the cache.

Generally I see three approaches how to make values of memory and
variables sensitive to the active thread:
a - make the memory cache reflect the active thread; that means having
n caches for n threads
b - use just one cache and invalidate it whenever the address mapping changes
c - do not use the cache at all

So far I tried to implement the way b), because it seems to require
the least changes in CDT. Any opinion which approach is the most
suitable would be welcomed.

For the way b) I need to detect when the address space mapping
changed, which is:
a - if the current thread in the debugger changed (by hitting a
breakpoint or switching from the IDE)
b - contents of special registers of the current cpu/thread changed
c - contents of the TLB of the current cpu changed (I should be able
to obtain the information about TLB from my VM)

and then I need to:
a - invalidate the cache and maybe even the values of evaluated variables in CDT
b - switch GDB to the new active thread (that issues the 'Hg' remote
command to the VM, so the VM will send memory contents for the right
cpu/thread)

I performed the detection of the thread change by implementing
IDebugContextListener (that is registered in the DebugContextManager)
and waiting
for the DebugContextEvent activate events. However this has a
shortcomming: the event is raised also if
the programmer debugs just a single thread (e.g. by stepping). Thus
the cache is invalidated more often than is needed.

Is there any other way to detect change of the currently debugged
thread? And, by the way, how can I detect the change of cpu registers?

2 - I observed another problem with the memory view. Let us suppose
that we have a separated memory at addresses 0x20000010-0x20000020
(memory mapped device, a special ROM memory, or maybe even 4kB mapped
page with no mapped siblings in a userspace C++ app). If the
programmer wants to show the contents of memory from 0x20000000 of
length 256(0x100) bytes, he will get the memory view full of question
marks. That is because GDB is not successful to read the 0x20000000
address and then CDT considers the memory block "0x20000000 -
0x200000FF" being invalid. The problem is that after invaliding the
"0x20000000 - 0x200000FF" block the programmer is not allowed to see
the "0x20000010 - 0x20000020" block in the memory view.

What about adding a refresh button to the memory view? The programmer
who really thinks that something should be in the "0x20000010 -
0x20000020" block would use the refresh button to be certain that the
block is/is not valid.

Regards,
Tomas