> -----Original Message----- > From: Greg Clayton [mailto:clayb...@gmail.com] > Sent: Tuesday, 19 September, 2017 9:48 PM > To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com> > Cc: lldb-dev@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.krasnu...@synopsys.com > <mailto:tatyana.krasnu...@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-boun...@lists.llvm.org] On Behalf Of > Greg Clayton via lldb-dev > Sent: Tuesday, 19 September, 2017 6:06 PM > To: cui bixiong <cuibixi...@gmail.com > <mailto:cuibixi...@gmail.com> > > Cc: lldb-dev@lists.llvm.org <mailto:lldb-dev@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 > <cuibixi...@gmail.com <mailto:cuibixi...@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 > <clayb...@gmail.com <mailto:clayb...@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb- > d...@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=> > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
