Re: [PATCH 0/2] Fix gdbserver/linux memory access regression

[Luis Machado <luis.machado@arm.com>]

On 5/4/22 10:11, Luis Machado via Gdb-patches wrote:
> On 5/3/22 15:24, Pedro Alves wrote:
>> On 2022-04-19 23:47, Pedro Alves wrote:
>>> The recent change to make GDBserver always access memory via
>>> /proc/pid/mem caused a regression in
>>> gdb.threads/access-mem-running-thread-exit.exp that I somehow missed.
>>> This is actually a pre-existing GDBserver issue being now exposed.
>>>
>>> Patch #2 fixes the GDBserver bug.
>>>
>>> Patch #1 fixes the gdb.threads/access-mem-running-thread-exit.exp
>>> testcase itself -- it doesn't run properly against
>>> --target_board=native-extended-gdbserver today.
>>>
>>
>> I'm pushing this in.
> 
> Just a heads-up, this seems to have regressed a few gdb.multi/*.exp 
> tests for aarch64-linux.
> 
> I see the following internal error for 
> gdb.multi/multi-target-continue.exp for example:
> 
> Starting program: 
> binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue 
> ^M
> Error in re-setting breakpoint 2: Remote connection closed^M
> ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: 
> inferior_thread: Assertion `current_thread_ != nullptr' failed.^M
> A problem internal to GDB has been detected,^M
> further debugging may prove unreliable.
> 
> I haven't investigated this yet.

Ok. I tracked this down to gdbserver crashing when trying to fetch the 
register cache using a nullptr for the thread pointer. This happens when 
trying to read memory, then the backend goes to try to figure out if it 
is 64-bit and then eventually tries to fetch the regcache with 
current_thread (nullptr).

I'm guessing we should really be using the process pointer if there 
isn't a valid thread pointer to fetch the register data.