This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Check for truncated registers in process_g_packet


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]