[PATCH 00/28] Decouple inferior_ptid/inferior_thread(); dup ptids in thread list (PR/25412)

Pedro Alves palves@redhat.com
Thu Jun 18 20:00:53 GMT 2020


On 4/17/20 9:20 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> I meant to mention, I skimmed through this series and didn't see
> anything objectionable.  It's hard to know about this kind of thing
> without trying it (which I didn't do); but IMO it's fine to land this
> and then iron out anything that pops up.
> 
> Pedro> After this, inferior_ptid still exists, but it is mostly read-only and
> Pedro> mainly used by target backend code.
> 
> Could it be made completely read-only?

We could, with e.g. a hack like in the attached patch.

That patch is sufficient to make GDB build on x86-64 GNU/Linux, but
certainly it would require more changes across all the native backends.
I'm not sure it really buys us much, since the remaining writes are just
as easily found by grepping for "inferior_ptid =".

> 
> Pedro> It is also relied on by a number
> Pedro> of target methods as a global input argument.  E.g., the target_resume
> Pedro> interface and the memory reading routines -- we still need it there
> Pedro> because we need to be able to access memory off of processes for which
> Pedro> we don't have a corresponding inferior/thread object, like when
> Pedro> handling forks.  Maybe we could pass down a context explicitly to
> Pedro> target_read_memory, etc.
> 
> This sounds like a good direction.

Thanks,
Pedro Alves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-inferior_ptid_t.patch
Type: text/x-patch
Size: 8082 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb-patches/attachments/20200618/3ac84384/attachment.bin>


More information about the Gdb-patches mailing list