----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3203/ -----------------------------------------------------------
(Updated Nov. 12, 2015, 4:39 p.m.) Review request for Default. Repository: gem5 Description ------- Changeset 11209:83e890c83564 \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- arm: Remote GDB: register xfer for AArch32 This patch stops remote gdb from panicking when connecting to a 32-bit target. We send the response to the g-packet from the buffer and the size in GdbRegCache.size. Both the buffer is allocated, and the size is set, at RemoteGDB object instantiation time, which is before we know if we will be running an AArch32 or AArch64 workload; therefore the longest possible size is assumed. The problem is that at actual packet processing time, if we are in AArch32 mode with its smaller register set, we still answer the whole buffer and gdb panics from seeing the oversized packet. To avoid this, I set the 'size' member to the correct value when processing each g-packet, according to whether we are in 32- or 64-bit mode. Another problem is the order in which register values are transferred. Ideally, we should serve gdb with a feature descriptor XML document. For now, I simply put in the default offsets assumed by gdb 7.10 in the absence of feature descriptors. Also in the absence of feature descriptors, gdb expects that the CPU has extended-precision FP registers (96 bits wide). This situation is beyond the simple design of the reg cache as a union of uint8/... arrays. In my opinion, it is worth improving the general union-based design (and possibly implementing feature descriptors) before fixing FPs in this case; therefore this patch simply transfers zeros to gdb, and ignores FP values coming from gdb. Diffs (updated) ----- src/sim/system.cc 7a9eeecf2b52 Diff: http://reviews.gem5.org/r/3203/diff/ Testing ------- Tested with gdb-7.10 configured with "--target=arm-linux-gnueabihf" connecting to gem5 running an arm-linux-gnueabihf binary in SE mode. Tested also with gdb-7.10 configured with "--target=aarch64-linux-gnu" connecting to gem5 running an aarch64-linux-gnu binary in SE mode to ensure against AArch64 regressions. Note that even with this patch, remote debugging of 32-bit ARM is still not useful because of problems with inserting breakpoints which I address in a separate patch. Thanks, Boris Shingarov _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
