It looks like the comInstEventQueue will actually help with this quite a bit. It's currently used to stop the simulation after a certain number of instructions, but it can just as easily (I think) be used to trap into GDB after a single instruction, or to get it to break into GDB initially at the next instruction boundary. There might be some weirdness with O3, for instance, and it not expecting the context to change when it services those events. Hopefully that wouldn't be too painful to fix if it does turn out to be a problem.
Gabe On Mon, Nov 24, 2014 at 10:18 PM, Gabe Black <gabebl...@google.com> wrote: > 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
