Check for truncated registers in process_g_packet

[Simon Marchi]

On 2017-08-25 12:53, Yao Qi wrote:
> This patch 9dc193c causes a regression,
> 
> $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver
> multi-arch-exec.exp"
> FAIL: gdb.multi/multi-arch-exec.exp: continue across exec that changes
> architecture
> 
> This test passes on the previous commit.  The test
> passes also if I revert this commit on mainline.

 From what I can see, the line that causes the problem is

   stop_pc = regcache_read_pc (get_thread_regcache (ecs->ptid));

at infrun.c:5321.  At this point, the process we are debugging has 
exec'ed.  It used to be a 64-bits process, it is now a 32-bits process.  
However, current_inferior_->gdbarch still points to the 64-bits gdbarch. 
  It's only the follow_exec call a few lines below that will update it to 
the new gdbarch.  By reading the PC, we send a g packet.  The response 
contains the registers of a 32-bits process, but we interpret them as 
those of a 64-bits process (because get_remote_arch_state uses 
current_inferior_->gdbarch).

If I move the line mentioned above just after the follow_exec call, gdb 
interprets the g reply with the right/new gdbarch, so the test case 
works.  I don't know if it breaks anything else, but so far I didn't 
find anything before that point that relied on stop_pc.  I sent that 
change to the buildbot to check.

So from what I understand, it looks like a pre-existing bug that this 
patch uncovered.  I think we were interpreting the g reply containing 
32-bits registers using the 64-bits register map all along, which that 
stop_pc had a bogus value.

To confirm this, I checked out the commit just prior this patch.  I see 
stop_pc having a value of 0 (it could be anything I guess).  If I move 
the assignment of stop_pc just after follow_exec, I see a value of 
0xf7fd9a20.  That value is the mapping address of the dynamic loader in 
the process:

   f7fd9000-f7ffb000 r-xp 00000000 fc:01 395792                           
   /lib/i386-linux-gnu/ld-2.23.so

plus the entry point in it:

   Entry point address:               0xa20

so it makes sense that the process is stopped at this address.

Simon