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

[Tomas Martinec <fyzmat@xxxxxxxxx>]

Well ...,

some my conclusions were wrong, because of this issues:

1 - the memory cache is supposed to store memory block just during one
suspended part of the session. When the session is resumed and
suspended again, the cache is used to monitor changes in the memory.

2 - the memory view monitors are internally linked with the
appropriate memory space of the debugged process. That is fine, but it
is not shown in the GUI. I personally find that confusing, especially
when I restart debugging session and expect the configured memory
monitors to be linked with the current debugging session and not the
previous stopped one. IMHO I would relink the memory monitors of
restarted session, or display the context of each memory monitor, or
at least delete the memory monitors of stopped session after restart.

3 - a probable bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=347845

> 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.

This is a limitation of gdb. I have already started discussing it on
gdb mailing list: http://sourceware.org/ml/gdb/2011-05/msg00138.html.
I might be able to teach gdb providing a memory map of the debugged
process generally (or thread in my case). Eclipse could then use the
memory map to check whether the read memory block is really whole
unreadable.

I can try to add such a command to the official version of gdb. If it
is successful, would you accept a patch that would use memory map from
gdb to ensure that a whole memory block is unreadable?

> 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.

That is true only until the programmer resumes/steps the debuggee.
After the resume the cache (fCommandCache of MIMemory) seems to be
invalidated.

> 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.

I am still wondering how to solve it. I found out that the gdb command
for reading the memory uses --thread option. The thread of the option
is determined in fetchMemoryBlock method of GdbMemoryBlock. There is
some mechanism in this class that uses memory space aware block. But
so far it seems that this mechanism is not used at all. Also the
context is probably supposed to be a process, not a thread.

Since the cache is flushed after resume I just need to use the context
(thread) of the shown memory monitor in fetchMemoryBlock. The only way
how the addressing mode could be changed during suspended period of
debugging session is by changing special registers. So that should be
the only thing I need to detect in my plugin.

Regards:),
Tomas