On Thursday 22 October 2009, Øyvind Harboe wrote: > 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? ... > > > > 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?
Sure. > I don't understand, much, what the mrc/mcr machine > code instructions do, I just copy & paste them. How > about using the same syntax? Syntax, yes. Register a parser that handles it iff the underlying core exports the relevant method. MRC == Move to Register from Coprocessor MCR == Move to Coprocessor from Register And there are variants (e.g. two-registers) ... you basically get ARM register(s) and a boatload of core-specific bits to pass, most of which must be zero in current usage. Some (all?) of the modern floating point is a thin veneer over coprocessor instructions. > > And then there's stuff like CM3 which doesn't even > > have coprocessor support ... > > I don't even know what CM3 is... Cortex-M3. :) > > 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. Yeah, and it's *far* from simple. But one mus after all keep one's eyes on a goal! Just getting kernel debug working will be enough to keep folk busy. The other bits should be there in mind too, helping to avoid overly constrained approaches. > Doesn't this require instrumenting the kernel? How do you handle > the case a sw breakpoint is swapped out to the disk? Hey, I don't enable swapping. You're talking about a kernel built by a crazyperson. ;) Re instrumenting ... maybe a bit. There are already context switch hooks for saving state. I don't think it'd be unreasonable to expect a Kconfig option which saves debug state. > 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... And attention from some GDB experts. :) > >> Recently made more general: > >> > >> - virtual to physical address translation > >> - physical memory read/write > >> > > > > Yeah, that seemed like the right direction. > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
