Actually we have some patches that enable remote gdb for x86, including SE mode. They were done by an intern we had this past summer. They need a little cleaning up and merging with the head before being posted, and I haven't had time for that, but if you'd like I can post them anyway.
I don't recall running into the mid-instruction interrupt problem, but we did run into the single-step issue, and in fact did go and implement a real single-step mode on the CPU model. I can try and post those patches tomorrow (sans clean-up) if you think they'd be helpful. Steve On Mon, Nov 24, 2014 at 9:51 PM, Gabe Black via gem5-dev <gem5-dev@gem5.org> wrote: > I'm working on adding remote GDB support for x86, and I've noticed a couple > of rough edges I'd like to smooth out somehow. > > First, when GDB attaches, a pollEvent will be added which will give the GDB > stub control immediately. The context being interrupted might not be on an > instruction boundary. For instance, it might be a memory operation that > hasn't completed, or it could be a microop in the middle of a macroop. > Presumably GDB only attaches once or twice a run so this isn't as big a > deal for ISAs which have only a few macroops (ARM for instance), but it's > Russian roulette with only one empty chamber on an ISA like x86. To address > that problem, I'm hoping to add a function to the interrupt controllers to > allow injecting a fake interrupt. The fake interrupt would only happen at a > clean commit point, so GDB would only take over when it was safe. This > seems like the least intrusive way to fix this problem. > > Second, I see that most ISAs implement single stepping by figuring out what > the current instruction is, decoding it, and then adding a PC event > wherever you might end up next. First of all, that involves reading and > decoding an instruction on the side and trying to predict where execution > is going to go. That works (mostly), but it's a bit cumbersome. Second, > that breaks down if you have a branch which can (or does) branch to itself. > In that case you'd set the PC event on the current instruction, and when > you started execution you'd immediately trigger it without actually > executing the instruction. What you need is something that would really > trigger after the current instruction, regardless of where execution was > headed next. I'm not sure what the best way to handle that is. > > Gabe > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
