One of the issues here is the ability to capture the context of the
current debugging situation, and it depends on a whole lot of variables.
With JTAG gdbservers it may not care that much about the difference in
programs at the developer/process/OS level. It may simply provide static
single thread per core. There is not enough information here, but, in
this instance, it can be represented with a single target to be seen by
LLDB. LLDB will have to do the heavy lifting at this point to switch
archs and locate 'real' thread information which we have done in the
past with success. In this mode, the user at least gets a single
coherent view of what is being debugged. Single stepping from one 'arch'
to another can be possible seamlessly, given a good implementation.
The other situation, which is mentioned before, uses multiple targets.
This works correctly if you have multiple gdbservers for the separate
bits of what is being debugged, although, from a developer standpoint,
things get complicated:
1) There is no 'high level view' of the current debugging situation at
any present time.
2) There is no cooperation between the targets, _even_ if they share
resources like memory.
3) Single stepping from one target to the other is not seamless.
4) Events can be missed from one target whilst debugging the other.
5) goes on..
This is why last year I suggest we start preparing for some sort of
higher-level platform which can manage multiple targets in a way which
makes sense for a given architecture/soc/system/whatever. It can
understand memory can be shared between targets, and therefore
watchpoints can trigger events on different platforms. It can understand
in a single stepping situation there may be a need to switch targets
given a set of circumstances to allow for a seamless experience to
developers.
At this point, whilst multiple target debugging works, it's value can be
so much more. Especially given the targets LLDB is tending to support;
parts of larger SoCs.
Colin
On 13/01/2015 00:45, Jason Molenda wrote:
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
--
- Colin Riley
Games Technology Director
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft
This email and any attachments may contain confidential and /or privileged
information and is for use by the addressee only. If you are not the intended
recipient, please notify Codeplay Software Ltd immediately and delete the
message from your computer. You may not copy or forward it,or use or disclose
its contents to any other person. Any views or other information in this
message which do not relate to our business are not authorized by Codeplay
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd
does not accept any responsibility for any changes made to this message after
it was sent. Please note that Codeplay Software Ltd does not accept any
liability or responsibility for viruses and it is your responsibility to scan
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
