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:
(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
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 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 ...
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
> <[email protected]> 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:[email protected]] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Tuesday, 19 September, 2017 6:06 PM
> To: cui bixiong <[email protected]>
> Cc: [email protected]
> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>>:
> 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=s1muy0YuwDDElPQxgJ6vznc3dDBxkqEqdNbw6v9MesM&s=5prvINiyVrMl8bpYzRwFlVWxIlsjH79K0W9MyCGhDuM&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
> <[email protected] <mailto:[email protected]>> 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=s1muy0YuwDDElPQxgJ6vznc3dDBxkqEqdNbw6v9MesM&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,2f70726f6a2f6d746b31333836372f727369632d762f74657374696e672f4275696c64332f72697363762d68656c6c6f2e656c66#6c
> < 4> read packet: $#00
> error: process launch failed: 'A' packet returned an error: -1
>
>
>
> Best Regards
> --cuibixiong
> _______________________________________________
> lldb-dev mailing list
> [email protected] <mailto:[email protected]>
> 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=s1muy0YuwDDElPQxgJ6vznc3dDBxkqEqdNbw6v9MesM&s=Yl9wZ2nbojjqtk8CUuyh6ANapwgmBwf8jEC0CFcmGNk&e=>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
