Yes, please do. I'll keep working on it, and if I get something working I'll post some reviews as well. We can pick the parts of each that will work best. I like the sound of your idea, Ali, but I'll have to look into probe points. Are those supported on all the CPU models? I doubt they're supported under KVM, but that's a whole other issue.
Gabe On Mon, Nov 24, 2014 at 10:15 PM, Steve Reinhardt via gem5-dev < gem5-dev@gem5.org> wrote: > 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 > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
