Hi Boris, I have used remote GDB quite extensively over the last 2 years. Mostly for x86_64, but also a bit for ARM (32 bit). It always worked fine and still works fine. I'm running it on a 64-bit Arch Linux and they do not (yet) use the mentioned patch, as I've just verified.
Best regards, Nils On 05/03/2017 04:20 PM, Boris Shingarov wrote: > Hi Matthias, > > I want to understand this better. The original RSP server in gem5 > viewed the contents of G packet as an array of registers all of the same > width. So, if an architecture defines some 64-bit registers and some > 32-bit registers, this had lead to idiotic situations such as registers > having a fractional index. So about a year ago, I re-wrote register > representation in the G packet to use C structs instead. This new code > has been working well for me using both GDB and another RSP client which > we hope to present to the community (although that's quite another > story, for now what's relevant is just that there are two RSP clients > that I compared in how they talk to GEM5's RSP server). My main ISAs I > was using at the time, were PPC and MIPS, but I do remember that I did > test all other ISAs which has separate register layout definitions. You > don't say what ISA you are working with, but from your patch I presume > you are talking about x86_64, right? > > What I am not quite getting is how it is only the newer GDB that > breaks. If the fields in the struct are incorrectly packed, then > offsets of where register values are in the G packet, will be wrong no > matter which GDB version is on the client end. So this raises two > interesting questions. First, what is the extent of this problem across > versions of GDB -- have we always been affected? Second, what is the > extent across ISAs -- does this also break ARM and others? I mean, > these G packets have been used for some time, and at least *some* of it > worked to useful ends -- both in my own work, and I hear that others > have also used it for practical purposes. I would like to better > understand where the limit of that "some" is. Maybe others can chime in > saying things like "using remote GDB extensively and it works" or the > opposite? to have at least some kind of picture of whether people even > exercise that corner of the universe. > > Boris > > > -----"gem5-users" <[email protected] > <mailto:[email protected]>> wrote: ----- > To: <[email protected] <mailto:[email protected]>> > From: Matthias Hille > Sent by: "gem5-users" > Date: 05/02/2017 11:49AM > Subject: [gem5-users] Newer gdb versions break remote debugging > > Hi all, > > I noticed that newer gdb versions break the ability to attach a remote > debugger to debug simulated code. > The good thing is, I already figured out why. Starting with commit > 9dc193c3be > <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9dc193c3be85aafa60ceff57d3b0430af607b4ce> > gdb does bounds checking for every register you sent to it via the > remote debugging protocol. If a register is not sent complete it will > output "Truncated register xy in remote 'g' packet" and that's what > actually happens with the current gem5 version. > Gem5 transmits 23 registers (17 64bit regs and 7 32bit regs) that should > result in a total amount of 164 bytes. But it actually send 168 bytes, > making gdb believe it will receive a 24th register. For the 24th > register gdb expects a size of 10 bytes and hence complains about it and > refuses to continue working. > The reason for the 4 byte overlap is that the structure used to keep > register contents is 8-bytes aligned. > So my current fix is packing that struct so gem5 won't send the padding > bytes. (Diff is attached) > > I am not entirely sure if this breaks compilation for some of you. I > used #pragma pack() to tell the compiler to pack the struct, and most of > the compilers should support it. > > Cheers, > Matthias > _______________________________________________ > gem5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > [attachment "remoteDebugFix.diff" removed by Boris Shingarov/Employee/LW-US] > > <https://www.labware.com/2017NACEC> > > <https://www.facebook.com/pages/LabWare-Inc/160466077336230><https://plus.google.com/116884607850969454032/posts> > <http://www.linkedin.com/company/labware> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > <http://www.linkedin.com/company/labware> _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
