Re: [PATCH] Fix Cell debugging regression (Re: [PATCH] Use thread_info and inferior pointers more throughout)

[Pedro Alves <palves@redhat.com>]

On 06/27/2018 02:12 PM, Ulrich Weigand wrote:
> Pedro Alves wrote:
> 
>>> The change above switches the behavior to use the SPU architecture
>>> if GDB happens to interrupt SPU code.  This is wrong and causes
>>> internal GDB errors pretty much instantly when starting an SPU ...
>> Sorry, missed that.  Some comments here would be helpful.
> 
> Agreed.  :-)
>  
>> gdb/ChangeLog:
>> 2018-06-27  Pedro Alves  <palves@redhat.com>
>>
>> 	* proc-service.c (ps_lgetregs, ps_lsetregs, ps_lgetfpregs)
>> 	(ps_lsetfpregs): Use get_thread_main_regcache.
>> 	* regcache.c (get_thread_main_regcache): Define.
>> 	* regcache.h (get_thread_main_regcache): Declare.
> 
> This looks good to me as far as the architecture is concerned.
> 
> In the meantime I also noticed another potential issue (which is
> not related to multi-arch at all):
> 
>>  ps_err_e
>>  ps_lgetregs (struct ps_prochandle *ph, lwpid_t lwpid, prgregset_t gregset)
>>  {
>> -  ptid_t ptid = ptid_build (ptid_get_pid (ph->ptid), lwpid, 0);
>> -  struct regcache *regcache
>> -    = get_thread_arch_regcache (ptid, target_gdbarch ());
>> +  struct regcache *regcache = get_thread_regcache (ph->thread);
> 
> This change also assumes that ph->thread is the same thread
> as the one indicated by lwpid.  Looking at the callers of the
> various libthread_db routines that might result in a callback
> to the ps_...regs routines, it is not immediately obvious to
> me that this is actually true.  Are you sure this can never
> be called to look up registers of another thread?

Argh, no, I completely missed that.  Let me take a better look.

Thanks,
Pedro Alves