Greg Clayton wrote:
On Jul 1, 2014, at 6:04 AM, Matthew Gardiner <[email protected]> wrote:
Hi all,
I have modified my local copy of lldb in order that it can gdb-remote to an in-house
gdb-rsp server. However after I connect to my target, the target list command informs me
that my target's platform is "host".
e.g.
(lldb) target list
Current targets:
* target #0:
/home/mg11/src/main/devtools/main/heracles/csrgdbserver/test/examples/simple/kalgsd5te_hello.elf
( arch=kalimba-csr-unknown, platform=host, pid=1, state=stopped )
Is this correct for a embedded target connected over gdb-rsp?
No, you really should add a new platform that claims "kalimba-csr-unknown" as
its architecture.
Right, thanks. Am I correct to assume that I'll need to add kalimba
(architecture) and CSR (vendor) to llvm::Triple to really get this plan
to take-off?
And would this implementation of the PlatformKalimba reside solely
within lldb? I'm asking since I see that we have a command tool called
lldb-platform. (Does this fit into to my world of custom platforms for
embedded targets?).
When I invoke platform list I see:
(lldb) platform list
Available platforms:
host: Local Linux user platform plug-in.
remote-freebsd: Remote FreeBSD user platform plug-in.
remote-linux: Remote Linux user platform plug-in.
remote-windows: Remote Windows user platform plug-in.
remote-gdb-server: A platform that uses the GDB remote protocol as the
communication transport.
So I wondered why my target doesn't report remote-gdb-server as it's target.
Should it?
No, not unless you implement a lldb-platform style platform for
"kalimba-csr-unknown". The current lldb-platform speaks the GDB remote
protocol, but adds new packets.
Could someone clarify what this concept of platform means? I understand the concept of
the host as being the Machine/OS where the debugger user is worked at, and the target as
being the "thing being debugged", which could be co-located on the host (in
either a 32-bit or 64-bit form) or remotely located, in particular for an embedded
device, but where does the idea of the platform fit in?
Platforms do the following:
1 - Resolve executables (you might say "target create ls" and your platform could
say "oh, 'ls' is in /usr/local/kalimba/root/bin/ls)
2 - Give a list of supported architectures ("kalimba-csr-unknown" for your
platform)
3 - Find local copies of a binary when remote debugging and the dynamic loader gives a list of shared
libraries your binary is linking against (for iOS, the "remote-ios" can resolve
"/usr/lib/dyld" to be
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/dyld")
4 - Find debug symbols for your binaries (they might be cached in your
development kit folder)
5 - List processes that can be attached to (try "platform process list" after
launching LLDB)
6 - Attach to a process from #5
7 - Launch a new process
8 - upload/download files
9 - install executables
Thanks for this. I guess some of these actions can't really be mapped
into CSRs current embedded scenarios, since they have no OS or
filesystem. (Basically the instruction code is copied into the chip's
ROM/RAM/FLASH/whatever, and when the device is reset, the processor
understands which device/address to start to fetch from).
However some of these actions are applicable, and indeed useful. Our
current debugger has a poor way of mapping different ELFs to a
particular context - we only really support having just one (or zero)
ELFs for any particular running core - so option 4. may be of benefit.
5. and 6. are also relevant, although we don't have the real processes,
the concept of Process 1 in an
unattached/attached-running/attached-stopped state would be useful.
If you write a platform that recognizes "kalimba-csr-unknown", you can say:
(lldb) file /path/to/kalimba/a.out
And it will query all installed platforms and see if any claim the current architecture. If you
made "PlatformKalimba", your platform be matched up with the binary since #2 from above
in your platform would return "kalimba-csr-unknown", and your platform would
automatically be selected.
Yep, understood. Presumably to support this effort I'll need to augment
the ArchType and VendorType enumerations of llvm::Triple and the
relevant parseXXX:: and getXXXName:: functions, as I referred to above.
The way the "remote-gdb-server" is currently used it by other platforms (like
PlatformPOSIX) have a shared pointer to a platform as a member variable:
lldb::PlatformSP m_remote_platform_sp; // Allow multiple ways to connect
to a remote POSIX-compliant OS
And this platform can implement items 5-9, while the local subclass
"PlatformKalimba" can take care of doing the specific local file system kinds
of things (locating all development kits for Kalimba on the current host, finding all
things you have debug symbols for, resolve executables, etc). When you then connect to
your platform:
(lldb) platform connect <url>
Then your "PlatformKalimba" would then create a connection to a remote
lldb-platform (which is a GDB remote protocol based platform) if you ever require the
ability to do the steps 5-9 above. Otherwise, the platform is still useful for locating
local copies of your executables.
Oh, I see, we have a notion of the local and remote platforms when
working with embedded debug.
thanks for this help, Greg, it is somewhat clearer now.
Matt
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
