On Saturday 10 September 2016 23:27:15 Duane Ellis wrote: > > Do you know if there's a method to read registers that is usable in > > AArch32 > > and -64 execution states? > > NO - the basic technique is the same Insert an opcode - and use the DCC to > transfer data, but the opcodes are totally different.
OK. > > I'm wondering if AArch32 will require a complete, > > additional debug implementation. > > Yes, it should - because there are so many “exceptions” going on - that it > will become horrible messy code (it already is) But what are the differences from the perspective of an external debugger? I don't think execution state can change while we're in debug mode. DLR and DSPSR are available in both states. The method to access them is of course different. > > Cache maintenance is another aspect that > > apparently different in -32 and -64 states. MMU and virt2phys translations > > is the next. > > Don’t forget the Hypervisor translation layer that can occur also. Yes, that too. > > For synchronization, DSB exists in Aarch32 state, but the encoding > > is different to -64 state. T32 and A64 don't seem to have a common, usable > > subset. > > Oh AARCH64 is totally different. > > Here is an example you must be able to resolve > > The CPU has 4 Execution Levels EL0, EL1, EL2 and EL3 > EL0 - is user mode > EL1 - is kernel mode > EL2 - is hypervisor mode > EL3 - is “secure mode” - i.e.: crypto stuff. > > ELx - can be 32 or 64bit > The EL(x+1) decides if ELx is 32 or 64bit > Once something is 32bit - all lower EL numbers are 32bit. > > ARM32 instructions are *NOT* the same as AARCH64 instructions. > Note I use the term: “arm32” and “aarch64” - this is ARMs terms > Reason: 20+ years of “arm32” code in GDB … thus the name “arm” or “arm32” > means what you know today. And AARCH64 is the 64bit opcodes > > When you *STOP* the CPU - it can be in either 32 or 64bit mode. > When you force the CPU to change to a higher EL (i.e.: user -> kernel) the > opcodes change I'm aware of that. I'm also aware that the state can only change through an exception. > So this is the example: > > You have two operating systems - running a secure application in 32bit > secure - executing in user mode EL0-32bit You have a 64bit Linux > application - and it makes a SECURE request to the secure monitor (through > a few layers) > > For security reasons, the secure monitor does some simple checks - then > converts the system into a 32bit system and goes to EL0 When done, it > switches back to 64bit - and resumes the *other* EL0 application. > > Try to debug this. For the most part this is a gdb problem. From openocds point It's rather simple: in any execution state of a PE, be able to satisfy gdb's requests for memory or register read and write, breakpoints and properly signal when a core enters debug state. Shouldn't get any more complicated than that. > David is very correct - the only way to make this work is to 100% do it a > different way It is totally wrong to assume that any arm 32bit code is > reusable > It generally is not - it is horribly not it is also very wrong headed to > think you can reuse it. I don't think so. For the most part, e.g. setting a hw breakpoint is pretty much identical. The code in aarch64.c is mostly a copy&paste from cortex_a.c. The 32bit DCC accesses are identical, even the register offsets match ARMv7. Halt, resume and stepping uses the CTI, there is no equivalence in ARMv7. Memory Access mode of the debug port is unique, but as far as I can see we don't need to care about -32 vs. -64 state here. > Ok you can - but if you do it this way - you are writing code that is in a > “maze of twisty passages all alike” and the pirate (crash bug) will > suddenly appear and take all of your gold and treasure. Maybe, but anyway first we need to get it correct, then we can think of making it neat. Right now it's not correct or complete. BR, Matthias > > -Duane. ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
