[lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

Thu Jul 23 12:40:56 PDT 2020

Sounds like you got close. 

What does your target look like when you type:

(lldb) target list

I forgot to mention one thing that we do for ELF files:

We make sections named PT_LOAD[N] where in N starts at zero. We do this because this is essentially how dynamic loaders actually load the binary in an OS, so it makes it easier for us. All sections from the section headers that are contained within a program header, will be made children of the PT_LOAD section they belong to. It is also interesting to note that any sections that are not part of a program header, like say DWARF sections, will be left as top level sections. You can easily see how the sections are organized by doing:

(lldb) image dump sections test.elf

Or you can use the python interface to see this more clearly. In the example below I use the "lldb.target" global variable to get to the target and use special python properties to be able to iterate. Also, the modules list within a target has the list of executables where the first entry (lldb.target.modules[0]) is the main executable.

(lldb) script
>>> for section in lldb.target.modules[0].sections:
...     print(section)
... 
[0x0000000000000000-0x000000000000ffd0) libfoo.so.PT_LOAD[0]
[0x0000000000010000-0x00000000000101cc) libfoo.so.PT_LOAD[1]
[0x0000000000011000-0x0000000000011004) libfoo.so.PT_LOAD[2]
[0x0000000000000000-0x0000000000000000) libfoo.so..comment
[0x0000000000000000-0x0000000000000000) libfoo.so..ARM.attributes
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_str
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_loc
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_abbrev
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_info
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_ranges
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_macinfo
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_frame
[0x0000000000000000-0x0000000000000000) libfoo.so..debug_line
[0x0000000000000000-0x0000000000000000) libfoo.so..symtab
[0x0000000000000000-0x0000000000000000) libfoo.so..shstrtab
[0x0000000000000000-0x0000000000000000) libfoo.so..strtab

And you can iterate over the subsections within PT_LOAD[0] with python as well:

>>> for section in lldb.target.modules[0].sections[0]:
...     print(section)
... 
[0x0000000000000154-0x00000000000001ec) libfoo.so.PT_LOAD[0]..note.android.ident
[0x00000000000001ec-0x0000000000000210) libfoo.so.PT_LOAD[0]..note.gnu.build-id
[0x0000000000000210-0x0000000000000750) libfoo.so.PT_LOAD[0]..dynsym
[0x0000000000000750-0x00000000000007f8) libfoo.so.PT_LOAD[0]..gnu.version
[0x00000000000007f8-0x0000000000000838) libfoo.so.PT_LOAD[0]..gnu.version_r
[0x0000000000000838-0x00000000000009c4) libfoo.so.PT_LOAD[0]..gnu.hash
[0x00000000000009c4-0x0000000000000c6c) libfoo.so.PT_LOAD[0]..hash
[0x0000000000000c6c-0x00000000000011d0) libfoo.so.PT_LOAD[0]..dynstr
[0x00000000000011d0-0x00000000000012a8) libfoo.so.PT_LOAD[0]..rel.dyn
[0x00000000000012a8-0x0000000000001980) libfoo.so.PT_LOAD[0]..ARM.exidx
[0x0000000000001980-0x0000000000001a70) libfoo.so.PT_LOAD[0]..rel.plt
[0x0000000000001a70-0x0000000000001ad0) libfoo.so.PT_LOAD[0]..ARM.extab
[0x0000000000001ad0-0x0000000000003cb4) libfoo.so.PT_LOAD[0]..rodata
[0x0000000000003cb8-0x000000000000fdc4) libfoo.so.PT_LOAD[0]..text
[0x000000000000fdd0-0x000000000000ffd0) libfoo.so.PT_LOAD[0]..plt

We put a '.' character between parent sections and their child sections, so this makes things look a bit messy in the output ("libfoo.so" + "." + "PT_LOAD[0]" + "." + ".text").

So try doing this:

(lldb) target modules load –file test.elf –load –set-pc-to-entry PT_LOAD[0] <addr> PT_LOAD[1] <addr> ...

Specify the address for each PT_LOAD program header and let us know if this works?

Greg

> On Jul 23, 2020, at 12:16 PM, <lulle2007200 at gmail.com> <lulle2007200 at gmail.com> wrote:
> 
> Hello,
> i tried to do it like you described:
> Create target with 
> ‘target create --arch armv7-none-none test.elf’
> Connect to OpenOCD with
> ‘gdb-remote localhost:3333‘
> (In the original message, I didn’t mention explicitly that I was connecting to OpenOCD, sorry for that)
> Tried to load the executable to the STM32 with
> ‘target modules load –file test.elf –load –set-pc-to-entry’
> This failed with ‘error: one or more section name + load address pair must be specified’
> I tried again, but this time specified a section and an address.
> It didn’t fail, but didn’t load the specified section to the STM32 either.
> 
> “Is this a baseboard situation where you have an ELF file that has program headers with all of the correct load addresses?”
> Yes, I have an ELF file with multiple LOAD program headers.
> The entry point address and program header addresses are all set correctly.
>  
>  
> Von: Greg Clayton <clayborg at gmail.com> 
> Gesendet: Donnerstag, 23. Juli 2020 01:05
> An: lulle2007200 at gmail.com
> Cc: lldb-dev at lists.llvm.org
> Betreff: Re: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target
>  
> The --load option should work if all of the program headers have the right addresses. LLDB should try to load all PT_LOAD program headers into memory at the address that they are loaded at.
>  
> Is this a baseboard situation where you have an ELF file that has program headers with all of the correct load addresses? If so, you want to make sure that you specify no OS and no vendor when loading your target:
>  
> (lldb) target create --arch armv7-none-none
> 
> Why? Because when LLDB knows where is no OS and no vendor then it will select the right dynamic loader plug-in. This plug-in will automatically set the "load" address for all program headers to match the "file" address found in the ELF file. If LLDB believes you have an OS that you are running on, it will try and load a dynamic loader plugin that will wait until that plugin detects that your executable has been dynamically loaded and try to set the "load" address intelligently.
>  
> LLDB has the notion of "load" and "file" addresses. "file" addresses are addresses as they are found in each executable or shared library object file (ELF, mach-o, COFF, etc) that exists in your target. Once your program is running, the dynamic loader will try and determine the "load" address for each section within each executable using the dynamic loader plug-in. Dynamic loader plug-ins are loaded based off of the target triple in your target.
>  
> If your ELF file has the entry point correctly set, you can use the "--set-pc-to-entry" option.
>  
> So if you have a static ELF file where all addresses are correct, you can probably use:
>  
> (lldb) target create --arch armv7-none-none a.out
> (lldb) target modules load --file a.out --load --set-pc-to-entry
> 
> You can also set your load addresses manually using this command by specifying the any number of section name + section address tuples:
>  
> (lldb) target create --arch armv7-none-none a.out
> (lldb) target modules load --file a.out --load --set-pc-to-entry .text 0x200000 .data 0x300000
>  
>  
>  
>> On Jul 22, 2020, at 9:10 AM, via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>  
>> Hello,
>> we are trying to debug firmware running on a stm32 using OpenOCD and LLDB.
>> GNU-GDB provides a ‘load’ command to load the sections from an ELF file to the target device.
>> We have tried to use ‘target modules load --load’ command to load ELF sections to a specific address, but that didn’t work.
>> If there is a way at all, what is the proper way to load the executable to the target device with LLDB?
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <https://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/20200723/08510089/attachment-0001.html>