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

Yao Qi
2017-09-05T10:37:41Z

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 (é½å°§)