On Fri, Oct 23, 2009 at 2:09 AM, David Brownell <[email protected]> wrote: > On Thursday 22 October 2009, Øyvind Harboe wrote: >> It would be advantageous to move in the direction of >> exposing common target functionality through the >> target->type polymorphic interface. >> >> Here are some on my list: >> >> - cp15 manipulation. The cp15 register exists across a wide >> range of arm targets. Perhaps mrc/mcr instructions in a >> more general way? cp15 is an interesting case because >> target->type is not really arm specific, but since we don't >> have C++ w/support multiple interfaces per class, etc. >> we have to make do best we can. Perhaps simply returning >> "unsupported" by default will be a good way to go here. > > We need some sort of "generic ARM" core code. > > But in this case I think we should start with syntax, > not implementation. mrc/mcr is more generic, yes, > and cp15 registers are core-specific.
Agreed on the syntax. That generic command should use a generic interface though. Right? I don't understand, much, what the mrc/mcr machine code instructions do, I just copy & paste them. How about using the same syntax? > And then there's stuff like CM3 which doesn't even > have coprocessor support ... I don't even know what CM3 is... > I suspect we'll know we're done with this when we can handle > two distinct scenarios cleanly: > > - Linux kernel debugging, which runs with MMU active and > basically uses a fixed MMU context; > > - Linux userspace debugging (via GDB!), which also runs > with MMU active but where the MMU context changes. > > So for example, we'd want to have a breakpoint apply when > one particular task is active ... but not when a different > task's MMU context is in use. This would be *neat* to have in place. A real powerfeature. Doesn't this require instrumenting the kernel? How do you handle the case a sw breakpoint is swapped out to the disk? GDB uses one GDB session per MMU context, right? I have not seen a concept of multiple address spaces where symbol tables overlap... At this point OpenOCD should be able to handle a single MMU context more or less reasonably well. Perhaps we need to allow multiple GDB sessions against the same target with one MMU context for each GDB session? Definitely deserves a new thread... >> Recently made more general: >> >> - virtual to physical address translation >> - physical memory read/write >> > > Yeah, that seemed like the right direction. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
