This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/7] Pass ptid to target_ops register methods
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: <gdb-patches at sourceware dot org>
- Date: Wed, 8 Mar 2017 12:02:46 -0500
- Subject: Re: [PATCH 0/7] Pass ptid to target_ops register methods
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=ericsson.com;
- References: <20170308164140.7281-1-simon.marchi@ericsson.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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