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
