[lldb-dev] How can lldb debug a remote bare-metal platform?

Tatyana Krasnukha via lldb-dev lldb-dev at lists.llvm.org
Tue Sep 19 13:49:59 PDT 2017 

> -----Original Message-----
> From: Greg Clayton [mailto:clayborg at gmail.com]
> Sent: Tuesday, 19 September, 2017 9:48 PM
> To: Tatyana Krasnukha <Tatyana.Krasnukha at synopsys.com>
> Cc: lldb-dev at lists.llvm.org
> Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal platform?
> 
> So the problem is bare boards have no dynamic loader. There is a
> DynamicLoaderStatic which will load files at the address that they are
> specified in the object files. When you load your ELF file using:
> 
> (lldb) file /path/to/foo.elf
> 
> What does:
> 
> (lldb) target list
> 
> show as the output? You might want to specify "none" for both the vendor
> and OS in your target triple when creating your target:
> 

It shows just what expected: * target #0: xxx.elf ( arch=arc-*-*, platform=host )

> (lldb) file --arch armv7-none-none /path/to/foo.elf
> 
> This specifies there is no vendor (first "none" in the triple) and no operating
> system  (second "none" in the triple). The target's triple helps it select the
> right plug-ins to use like the dynamic load plug-in (which tells LLDB where
> sections from binaries got loaded), runtime plug-ins and much more.
> 
> 
> So you might try:
> 
> (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf

----set-pc-to-entry, not --set-pc-to-entry. May by typo in sources.

‘target modules load --load ----set-pc-to-entry --slide 0’ is enough, but just compare this text with ‘load’ in gdb… Looks like someone hates bare-metal developers))

> 
> Or, you can specify the addresses of all the sections using:
> 
> (lldb) target modules load --load --set-pc-to-entry --file /path/to/foo.elf .text
> 0x1000 .data 0x2000 ....

This is a good feature, but again, how often is it needed comparing with simple load…

> 
> This allows you to completely control where each section goes and possibly
> skip other sections. It also informs LLDB that sections have been loaded at
> specific addresses.
> 
> FYI: We will have to tweak LLDB for baseboard support as it has been used bit
> by a few folks (check the "svn blame" for who added the "--load" option and
> possibly contact them) but I am sure it needs to be improved.
> 
> So try specifying "--arch <arch>-none-none" and see where that gets you. It
> should select the right dynamic loader plug-in for you.
> 
> A bit more explanation about loading. LLDB has the notion of "file addresses"
> and "load addresses". A file address is valid for one file only, and it is the
> same as the addresses that are contained within the object file (ELF, Mach-O,
> COFF). When breakpoints are set by file + line or by name, we resolve these
> to "section .text + 100 in file foo.elf". Breakpoints can't be set until a section
> has a "load address" which will tell us where each section actually is mapped
> inside the process being debugged. For bare boards there is no dynamic
> linker that tell us '".text" was loaded at address 0x1230000'. If the
> DynamicLoaderStatic is selected for a target, which is done by having no OS in
> the target triple for the target, it will set the load address for the sections to
> match the "file addresses" and breakpoints will then be set. When a section
> is "loaded", a message is sent around LLDB to indicate a section was loaded,
> and all breakpoints will now be able to resolve themselves (get the "load
> address" for each "file address" for each breakpoint) and they will be set in
> the debugged process. Your extra step where you need LLDB to load your
> ELF file is now in the mix as well.
> 
> So I would recommend:
> 1 - create your target first:
>     (lldb) file --arch armv7-none-none /path/to/foo.elf
> 2 - attach to the baseboard
>     (lldb) gdb-remote ....
> 3 - load the file in memory
>     (lldb) target modules load --load --set-pc-to-entry --slide 0 --file
> /path/to/foo.elf
> 4 - set breakpoints now
>     (lldb) breakpoint set ...
> 

Of course I used incorrect order of commands, I just wanted to note that ObjectFile::LoadInMemory should set error status when it cannot write memory.

> 
> Usually you can set the breakpoints before your attach, but in your case you
> probably want to load the ELF file before you set breakpoints, otherwise you
> might end up setting breakpoints as soon as the "gdb-remote ..." attach
> happens since the DynamicLoaderStatic will correctly set the load addresses
> of all your sections after attaching which will cause breakpoint to resolve and
> attempt write traps to memory. Then if we load the ELF file in step #3 and
> when it writes all of the ELF sections to memory it will overwrite the
> breakpoint traps we set. So try the above flow and let us know how things
> go.
> 
> Greg Clayton
> 
> 
> 
> 
> 	On Sep 19, 2017, at 11:21 AM, Tatyana Krasnukha
> <Tatyana.Krasnukha at synopsys.com
> <mailto:Tatyana.Krasnukha at synopsys.com> > wrote:
> 
> 	Hello,
> 
> 	‘target modules load -lp’  fails with error “one or more section name
> + load address pair must be specified”, works only with --slide option.
> 
> 	Another issue is that if breakpoint is set, Process::WriteMemory
> return zero and ObjectFile::LoadInMemory interprets it as an error without
> setting appropriate status. Thus, user sees nothing in output as if command
> succeeds.
> 
> 	Thanks,
> 	Tatyana
> 
> 	From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of
> Greg Clayton via lldb-dev
> 	Sent: Tuesday, 19 September, 2017 6:06 PM
> 	To: cui bixiong <cuibixiong at gmail.com
> <mailto:cuibixiong at gmail.com> >
> 	Cc: lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
> 	Subject: Re: [lldb-dev] How can lldb debug a remote bare-metal
> platform?
> 
> 	Load like "target modules load" has a --load option that will load the
> ELF into memory. I think it should do what you want. Let me know how it
> goes.
> 
> 	Greg Clayton
> 
> 
> 		On Sep 18, 2017, at 9:58 PM, cui bixiong
> <cuibixiong at gmail.com <mailto:cuibixiong at gmail.com> > wrote:
> 
> 		Hi Greg:
> 
> 		    It's worked, thank you!, but I still have a question, in GNU-
> GDB which provide `load` command to download a ELF file into bare-board, in
> LLDB support those features? should I dump a binary file and use lldb "target
> module load" to replace 'load' command?
> 
> 		​Best Regards
> 		--cuibixiong​
> 
> 
> 		2017-09-18 23:53 GMT+08:00 Greg Clayton
> <clayborg at gmail.com <mailto:clayborg at gmail.com> >:
> 
> 			So when launching a GDB server there are two flows:
> 
> 			1 - When you connect you already have a process
> 			2 - You will connect, then launch or attach to a
> process
> 
> 			LLDB tries to see if there is a process by sending the
> "qfThreadInfo" packet. As you see below, it responds with on character "l"
> which means  "end of the thread list". Since no thread IDs were returned,
> this makes LLDB believe that there is no process on the other end. So later
> when you try to say "process launch", it tries to send the "A" packet which
> tries to launch your program by sending the name of the process file to
> launch.
> 
> 			There was recently an OpenOCD patch to work
> around this with:
> 
> 			https://reviews.llvm.org/D37934
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__reviews.llvm.org_D37934&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&
> r=yfnu24japkhNGh-
> WqJObHXmH3mINtC_2FO828lrNpM0&m=s1muy0YuwDDElPQxgJ6vznc3dDBx
> kqEqdNbw6v9MesM&s=5prvINiyVrMl8bpYzRwFlVWxIlsjH79K0W9MyCGhDu
> M&e=>
> 
> 			This fixed this issue and also made it read both sets of
> registers via the XML target packets.
> 
> 			That should make things work, but it would be better
> if we modified the OpenOCD GDB server to respond with a thread ID when
> asked about its thread with the "qfThreadInfo" packet. Since it is a bare
> board connection, it should respond with "1" (one) to the "qfThreadInfo"
> packet followed by "l" to the next ThreadInfo packet (read GDB protocol
> docs on this.
> 
> 			Let me know if the patch mentioned above (which is
> already checked in) fixed your issues.
> 
> 
> 
> 
> 				On Sep 17, 2017, at 3:50 AM, cui bixiong via
> lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org> > wrote:
> 
> 				Hi：
> 
> 				    Currently I porting lldb for Hifive1 (riscv
> bare board) w/ openocd 0.10.0, but it always show "error: Process must be
> launched."
> 
> 				    I use GNU gdb to remote connect and
> debugging w/ the same openocd + elf, it work OK.
> 
> 				    I want to know how to launch Process in
> bare board?
> 
> 				    thanks a lot!
> 
> 				$ lldb
> 				(lldb) log enable gdb-remote packets
> 				(lldb) target create Build3/riscv-hello.elf
> 				Current executable set to 'Build3/riscv-
> hello.elf' (riscv).
> 				(lldb) gdb-remote 172.27.113.29:3333
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__172.27.113.29-
> 3A3333_&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yfnu24japkhNGh-
> WqJObHXmH3mINtC_2FO828lrNpM0&m=s1muy0YuwDDElPQxgJ6vznc3dDBx
> kqEqdNbw6v9MesM&s=VOu2PpXUGoyMKI8l3ZgwFP5o1vdRygwBr4rzl-
> CmFX0&e=>
> 				<   1> send ack packet: +
> 				history[1] tid=0x44c8 <   1> send packet: +
> 				<   1> read packet: +
> 				<  19> send SendPacketNoLock 2 packet:
> $QStartNoAckMode#b0
> 				<   1> read packet: +
> 				<   6> read packet: $OK#9a
> 				<   1> send ack packet: +
> 				<  41> send SendPacketNoLock 2 packet:
> $qSupported:xmlRegisters=i386,arm,mips#12
> 				<  80> read packet:
> $PacketSize=3fff;qXfer:memory-map:read+;qXfer:features:read-
> ;QStartNoAckMode+#08
> 				<  26> send SendPacketNoLock 2 packet:
> $QThreadSuffixSupported#e4
> 				<   4> read packet: $#00
> 				<  27> send SendPacketNoLock 2 packet:
> $QListThreadsInStopReply#21
> 				<   4> read packet: $#00
> 				<  13> send SendPacketNoLock 2 packet:
> $qHostInfo#9b
> 				<   4> read packet: $#00
> 				<  10> send SendPacketNoLock 2 packet:
> $vCont?#49
> 				<   4> read packet: $#00
> 				<  27> send SendPacketNoLock 2 packet:
> $qVAttachOrWaitSupported#38
> 				<   4> read packet: $#00
> 				<  16> send SendPacketNoLock 2 packet:
> $qProcessInfo#dc
> 				<   4> read packet: $#00
> 				<   6> send SendPacketNoLock 2 packet:
> $qC#b4
> 				<   7> read packet: $QC0#c4
> 				<  16> send SendPacketNoLock 2 packet:
> $qfThreadInfo#bb
> 				<   5> read packet: $l#6c
> 				(lldb) thread list
> 				error: Process must be launched.
> 				(lldb) b main
> 				Breakpoint 1: where = riscv-hello.elf`main at
> hello.c:3, address = 0x20400230
> 				(lldb) thread continue
> 				error: invalid thread
> 				(lldb) process launch
> 				<  38> send SendPacketNoLock 2 packet:
> $QSetSTDIN:2f6465762f7074732f343238#b6
> 				<   4> read packet: $#00
> 				<  39> send SendPacketNoLock 2 packet:
> $QSetSTDOUT:2f6465762f7074732f343238#17
> 				<   4> read packet: $#00
> 				<  39> send SendPacketNoLock 2 packet:
> $QSetSTDERR:2f6465762f7074732f343238#08
> 				<   4> read packet: $#00
> 				<  21> send SendPacketNoLock 2 packet:
> $QSetDisableASLR:1#ce
> 				<   4> read packet: $#00
> 				<  23> send SendPacketNoLock 2 packet:
> $QSetDetachOnError:1#f8
> 				<   4> read packet: $#00
> 				<  21> send SendPacketNoLock 2 packet:
> $QLaunchArch:riscv#8b
> 				<   4> read packet: $#00
> 				<  33> send SendPacketNoLock 2 packet:
> $QEnvironment:BINARY_TYPE_HPC=#fd
> 				<   4> read packet: $#00
> 				< 115> send SendPacketNoLock 2 packet:
> $A104,0,2f70726f6a2f6d746b31333836372f727369632d762f74657374696e672f
> 4275696c64332f72697363762d68656c6c6f2e656c66#6c
> 				<   4> read packet: $#00
> 				error: process launch failed: 'A' packet
> returned an error: -1
> 
> 
> 
> 				Best Regards
> 				--cuibixiong
> 
> 	_______________________________________________
> 				lldb-dev mailing list
> 				lldb-dev at lists.llvm.org <mailto:lldb-
> dev at lists.llvm.org>
> 				http://lists.llvm.org/cgi-
> bin/mailman/listinfo/lldb-dev
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-
> 2Dbin_mailman_listinfo_lldb-
> 2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yfnu24japkhNGh-
> WqJObHXmH3mINtC_2FO828lrNpM0&m=s1muy0YuwDDElPQxgJ6vznc3dDBx
> kqEqdNbw6v9MesM&s=Yl9wZ2nbojjqtk8CUuyh6ANapwgmBwf8jEC0CFcmG
> Nk&e=>
>

More information about the lldb-dev mailing list