FWIW we were talking about this a little bit. Assuming I'm correct that you have one communication channel to the JTAG probe (one gdb-remote connection), when you step from aarch32 user process code to aarch64 hypervisor code it's not just an architecture change -- we're changing to an entirely different program (kernel versus user code).
This genuinely does need to be represented in lldb as two separate Targets that coexist simultaneously. Only one of them will be executing at any given time - so there would need to be some way for lldb to hand off from userland Target to kernel Target. That's definitely something new. If there are separate probes/gdb-remote communication channels for these -- maybe the kernel is running on one core and the user process on another -- then it's easy. The EFI example I mentioned earlier where a processor changes its mode (16/32, then 64 bit) as it starts up is not a good comparison. In that case a single program is being debugged through the entire transition - it's just the architecture that has changed mid-debug-session. J > On Jan 12, 2015, at 2:47 PM, Jason Molenda <jmole...@apple.com> wrote: > > I'm guessing the JTAG probe vends a single gdb-remote connection that is > either seeing the user-process aarch32 or the hypervisor aarch64 at any given > time. So you're stepping along in aarch32 mode and then it syscalls out to > aarch64, all within a single Target. > > I think this is akin to the folks doing the low-level startup routines on x86 > machines - it changes its architecture from 32-bit to 64-bit as it brings up > the system. From lldb's point of view this is a single Target that changes > architecture during the debug session. > > >> On Jan 12, 2015, at 2:36 PM, Greg Clayton <gclay...@apple.com> wrote: >> >> Yes you can: you can have one target for the 32 bit ARM and one for the 64 >> bit one. You currently can't have one target (process) be both 32 and 64 >> bit, but you can do this with two targets. I am guessing you would have one >> target that is debugging the user space process and one for the 64 bit >> hypervisor routine which I am assuming is the kernel? >> >> This is exactly why we developed LLDB with a modular plug-in based >> architecture. >> >> Greg >> >>> On Jan 12, 2015, at 2:07 PM, Ted Woodward <ted.woodw...@codeaurora.org> >>> wrote: >>> >>> Here’s a scenario I’m being asked about: >>> >>> A CPU is executing in AARCH32. LLDB is talking to a JTAG probe via gdb >>> remote. The user stops the program, and it’s in an Android user space >>> application. Can we single step through it, and then an AARCH64 Hypervisor >>> routine, in the same LLDB instance? What would we need to set up to do this? >>> >>> -- >>> Qualcomm Innovation Center, Inc. >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >>> Linux Foundation Collaborative Project >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
