This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix Cell debugging regression (Re: [PATCH] Use thread_info and inferior pointers more throughout)
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Wed, 27 Jun 2018 14:17:23 +0100
- Subject: Re: [PATCH] Fix Cell debugging regression (Re: [PATCH] Use thread_info and inferior pointers more throughout)
- References: <20180627131239.5F0D5D801C0@oc3748833570.ibm.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