RFC: Two small remote protocol extensions
Andrew Cagney
ac131313@ges.redhat.com
Fri Aug 23 12:39:00 GMT 2002
>> > ????? Memory is shared between threads, isn't it so ????
> This is yet another long overdue problem (I had hope it was fixed in
> recent releases) - gdb lumps together mult-process
> debugging with multi-tread debugging and it it does not
> excell in any of them.
You mean GNU/Linux?
> It seems to me that we have to handle multi-process debugging a-la
> vxWorks with a separate gdb instance per process and thus forget about it.
I guess you didn't mean GNU/Linux.
The GNU/Linux and Solaris thread implementation have a specific thread
that they use when doing memory operations. That behavour should
certainly be extended across the remote protocol so that a remote server
can more exactly mimic the behavour of a native GDB. GDB's view of the
target's address space is defined by what the target's process can see.
If the target's process can't see it, neither can GDB.
Should it be defined by ``Hg'' I guess that open to debate (current
implementation doesn't do anything here). However, I think it should be
well defined.
> When reading or writing memory, gdb specifies a thread. If it turns out
>> that the thread disappeared, GDB picks a thread, any thread (the
>> assumption being that all address spaces are pretty much similar).
>>
>> Mind you, I've seen thread implementations that implemented per-thread
>> local data using VM.
>
>
> It does not mean that everybody else should suffer, it is time to fix
> this youthful indiscretion.
Humor me. So who is suffering?
Andrew
More information about the Gdb
mailing list