Re: [PATCH] Don't send queries to the MI interpreter

[Pedro Alves <palves@redhat.com>]

On 02/10/2017 07:05 PM, Simon Marchi wrote:
> On 17-02-10 01:07 PM, Pedro Alves wrote:

>> So I think that to support multiple queries like that
>> the simplest / most natural would be to make each
>> UI above run on its own thread, so that each would have
>> its own independent stack/frames.
> 
> Indeed.  That represents a tremendous amount of work I imagine,
> putting the proper locking mechanisms in place...  And if you
> are holding a lock while the query is issued, it would still
> block some other things.

I had it working with a GIL/BKL-style lock, in the original
"new-console" prototype that was later rewritten into what
is "new-ui" today.  I.e,. even though we'd have multiple
threads, only one thread really runs at a time.  The idea
was that we'd start with a big lock, and then over time break
down the lock into more finer-grained locks.

Here:

https://github.com/palves/gdb/commits/palves/console-extra

- A thread per UI.  See the "Start a thread for each UI" patch.
- Per-UI readline (with a giant readline hack)
- Per-UI nurses/TUI instance (it really works!) :-)

The trouble is that this then trips on another nasty problem:

All ptrace calls targeting a process must be issued
from the thread that first attached to that inferior process.
The kernel rejects the ptrace call otherwise eith EIO/EINVAL
or some such, I don't recall which.  So on that branch, with
native debugging, if you start the inferior on UI #1, and then
try to read memory from UI #2, it fails...  If you instead
try the same against gdbserver, it all works, because in that
case gdbserver handles the ptrace calls, not gdb, so all
ptrace calls come from the same thread in that case.
So for native debugging, we'd need to marshall all ptrace
requests through the same thread...

Thanks,
Pedro Alves