Re: [PATCH 0/7] Pass ptid to target_ops register methods

[Simon Marchi <simon.marchi@ericsson.com>]

On 17-03-08 11:41 AM, Simon Marchi wrote:
> GDB uses global variables a lot to indirectly pass information about the debug
> context between functions.  This patch series tries to reduce this practice a
> tiny bit by adding a ptid parameter to the register access methods of the
> target_ops interface.  This removes a lot of direct references to inferior_ptid
> in low level code.  Instead, the callers of to_fetch_registers /
> to_store_registers / to_prepare_to_store provide the ptid on which to operate.
> 
> One of the goals is to reduce the number of times we need to save and restore
> inferior_ptid.  It should also make it easier to track down the context of why
> we are reading/writing registers of a certain thread by looking at the stack.
> 
> The buildbot shows good results x86 (32 and 64) and PowerPC.  s390 has some
> regressions, but I think it's unrelated:
> 
>   new FAIL: gdb.python/py-mi-events.exp: verify python support
>   new FAIL: gdb.python/py-mi-events.exp: check if python 2.4
>   PASS -> FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: other threads ran - unlocked
> 
> I built-tested a few other platforms:
> 
>  - mips64el/linux
>  - m68k/linux
>  - powerpc/linux
>  - powerpc/aix
>  - arm/linux
>  - aarch64/linux
>  - s390x/linux
>  - x86-64/windows (a x86_64-w64-mingw32 toolchain)
> 
> Here are the platforms I didn't test at all:
> 
>  - anything BSD
>  - OS X
> 
> I tried to identify all the locations impacted by this change and update them
> accordingly, but it's almost certain that I forgot or messed up some, sorry in
> advance.

Oh, and to give an idea of the impact on the number of references to inferior_ptid,
here are some non-scientific numbers.

Before:

gdb $ grep '[^_]inferior_ptid' *.c | wc -l
973

After:

gdb $ grep '[^_]inferior_ptid' *.c | wc -l
765