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

Wed Sep 20 00:34:38 PDT 2017

Yes, I think we still have a lot of development work for bare board , the
first important is  openocd + lldb work successful which openocd is mostly
common used tools for bare board

On Wed, Sep 20, 2017 at 6:24 AM, Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
> On Sep 19, 2017, at 1:49 PM, Tatyana Krasnukha <
> Tatyana.Krasnukha at synopsys.com> wrote:
>
> -----Original Message-----
> From: Greg Clayton [mailto:clayborg at gmail.com <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))
>
>
> As I said, we haven't done a lot of bare board development in LLDB as of
> yet.
>
>
>
> 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 is mostly used when using LLDB for symbolication. On MacOSX, the
> crashlogs contains just the address of the .text segment as all other
> segments are not rigidly slid, so we often do:
>
> (lldb) image load --file a.out __TEXT 0x100203000
>
> So it isn't needed for baseboard, but is much more geared toward OSs
> running binaries that are dynamically loaded.
>
> As I said before, we will have some growing pains with LLDB and bard
> boards, but lets make a solution that works for everyone. I would be happy
> to accept patches that allows us to not have to specify "--slide 0" if
> there is no OS in the target triple. We could also do patches where if a
> module is written to memory, it invalidates any breakpoints for the module
> that was just loaded and rewrites them into memory.
>
>
>
> 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.
>
>
> It should for sure. Feel free to submit any patches if this isn't
> happening.
>
>
>
> 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 <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
> <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 <cuibixiong at gmail.com>> >
> Cc: lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org
> <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 <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 <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
> <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=>
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170920/78a47c2a/attachment-0001.html>