Re: [PATCH 3/4] Add thread after updating gdbarch when exec'ing

[Yao Qi <qiyaoltc at gmail dot com>]

On 17-08-27 12:15:33, Simon Marchi wrote:
> As mentioned in the previous patch, we should avoid doing register reads
> after a process does an exec and before we've updated that inferior's
> gdbarch.  Otherwise, we may interpret the registers using the wrong
> architecture.  When a process does an exec with "follow-exec-mode new",
> a new inferior is added by follow_exec.  The gdbarch of that new
> inferior is at first set to some default value, probably specific to the
> gdb build (I get "i386" here), which may not be the right one.  It is
> updated later by the call to target_find_description.  Before that
> point, if we try to read the inferior's registers, we may not interpret
> them correctly.  This has been exposed by a failure in
> gdb.base/foll-exec-mode.exp after the previous patch, with:
> 
>   Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes)
> 
> The call to "add_thread" done just after adding the inferior is
> problematic, because it ends up reading the registers (because the ptid
> is re-used, we end up doing a switch_to_thread to it, which tries to
> update stop_pc).  The registers returned by gdbserver are the x86-64
> ones, while we try to interpret them using the "i386" gdbarch.

The analysis is great!

> 
> Postponing the call to add_thread to until the target
> description/gdbarch has been updated seems to fix the issue.

This imposes an odd restriction on using add_thread, that is, we must
keep in mind that we can't use add_thread until the inferior's gdbarch
or target description is updated.  The question in my mind is that why
do we need to update stop_pc in add_thread? or can we remove stop_pc?

-- 
Yao (齐尧)