So the good news is the DWARF seems to be valid.
I think LLDB is having problems with this ELF file because it is an object file (e_type == ET_REL) or because it has no program headers.
There were some changes made to LLDB where we would put any section headers that were contained in program headers inside of a section named for the program headers. So you will normally end up with sections in LLDB like:
PT_LOAD[0]
.note.android.ident
.note.gnu.build-id
.dynsym
.gnu.version
.gnu.version_r
.gnu.hash
.hash
.dynstr
.rel.dyn
.ARM.exidx
.rel.plt
.ARM.extab
.rodata
.text
.plt
PT_LOAD[1]
.fini_array
.data.rel.ro
.dynamic
.got
.got.plt
PT_LOAD[2]
.data
.bss
.comment
.ARM.attributes
.debug_str
.debug_loc
.debug_abbrev
.debug_info
.debug_ranges
.debug_macinfo
.debug_frame
.debug_line
.debug_aranges
.symtab
.shstrtab
.strtab
Note how any section that is contained within a program header is contained within a PT_LOAD[N] section.
If I load your ELF binary, I can set a breakpoint:
(lldb) b TestFunction.cpp:1
Breakpoint 1: where = ELFData.txt`::20000() + 4 at TestFunction.cpp:1:7, address = 0x0000000000000004
I can also view the line table that LLDB was able to parse:
(lldb) target modules dump line-table TestFunction.cpp
Line table for /test/E:/test/TestFunction.cpp in `ELFData.txt
0x0000000000000000: E:/test/TestFunction.cpp
0x0000000000000004: E:/test/TestFunction.cpp:1:7
0x000000000000000c: E:/test/TestFunction.cpp:2:7
0x0000000000000014: E:/test/TestFunction.cpp:3:7
0x000000000000001c: E:/test/TestFunction.cpp:4:7
0x000000000000002a: E:/test/TestFunction.cpp:4:7
But if we look at the sections, we see the sections had their addresses changed. If we look at what is in the ELF file:
$ elf.py /tmp/ELFData.txt
ELF: /tmp/ELFData.txt (x86_64)
ELF Header:
e_ident[EI_MAG0 ] = 0x7f
e_ident[EI_MAG1 ] = 0x45 ‘E’
e_ident[EI_MAG2 ] = 0x4c ‘L’
e_ident[EI_MAG3 ] = 0x46 ‘F’
e_ident[EI_CLASS ] = 0x02 ELFCLASS64
e_ident[EI_DATA ] = 0x01 ELFDATA2LSB
e_ident[EI_VERSION ] = 0x01
e_ident[EI_OSABI ] = 0x00 ELFOSABI_NONE
e_ident[EI_ABIVERSION] = 0x00
e_type = 0x0001 ET_REL
e_machine = 0x003e EM_X86_64
e_version = 0x00000001
e_entry = 0x0000000000000000
e_phoff = 0x0000000000000000
e_shoff = 0x0000000000000568
e_flags = 0x00000000
e_ehsize = 0x0040
e_phentsize = 0x0000
e_phnum = 0x0000
e_shentsize = 0x0040
e_shnum = 0x0011
e_shstrndx = 0x0001
Section Headers:
Index sh_name sh_type sh_flags sh_addr sh_offset sh_size sh_link sh_info sh_addr_a sh_entsize
======= ---------- ----------------- ------------------ ------------------ ------------------ ------------------ ---------- ---------- ------------------ ------------------
[ 0] 0x00000000 SHT_NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000 0x00000000 0x0000000000000000 0x0000000000000000
[ 1] 0x0000008b SHT_STRTAB 0x0000000000000000 0x0000000000000000 0x00000000000004c0 0x00000000000000a1 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .strtab
[ 2] 0x0000000f SHT_PROGBITS 0x0000000000000006 0x00000137f1030000 0x0000000000000040 0x000000000000002a 0x00000000 0x00000000 0x0000000000000010 0x0000000000000000 .text ( SHF_ALLOC SHF_EXECINSTR )
[ 3] 0x0000003f SHT_PROGBITS 0x0000000000000030 0x0000000000000000 0x000000000000006a 0x000000000000003e 0x00000000 0x00000000 0x0000000000000001 0x0000000000000001 .debug_str ( SHF_MERGE SHF_STRINGS )
[ 4] 0x00000001 SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000000a8 0x0000000000000043 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_abbrev
[ 5] 0x0000004f SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000000eb 0x000000000000008d 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_info
[ 6] 0x0000004a SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000310 0x0000000000000150 0x00000010 0x00000005 0x0000000000000008 0x0000000000000018 .rela.debug_info
[ 7] 0x0000002f SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x0000000000000178 0x000000000000001c 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_pubnames
[ 8] 0x0000002a SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000460 0x0000000000000018 0x00000010 0x00000007 0x0000000000000008 0x0000000000000018 .rela.debug_pubnames
[ 9] 0x0000001a SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x0000000000000194 0x0000000000000026 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_pubtypes
[ 10] 0x00000015 SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000478 0x0000000000000018 0x00000010 0x00000009 0x0000000000000008 0x0000000000000018 .rela.debug_pubtypes
[ 11] 0x0000005b SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000001ba 0x0000000000000000 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .note.GNU-stack
[ 12] 0x00000081 SHT_ARM_EXIDX 0x0000000000000002 0x00000137f1040000 0x00000000000001c0 0x0000000000000038 0x00000000 0x00000000 0x0000000000000008 0x0000000000000000 .eh_frame ( SHF_ALLOC )
[ 13] 0x0000007c SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000490 0x0000000000000018 0x00000010 0x0000000c 0x0000000000000008 0x0000000000000018 .rela.eh_frame
[ 14] 0x00000070 SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000001f8 0x0000000000000052 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_line
[ 15] 0x0000006b SHT_RELA 0x0000000000000000 0x0000000000000000 0x00000000000004a8 0x0000000000000018 0x00000010 0x0000000e 0x0000000000000008 0x0000000000000018 .rela.debug_line
[ 16] 0x00000093 SHT_SYMTAB 0x0000000000000000 0x0000000000000000 0x0000000000000250 0x00000000000000c0 0x00000001 0x00000007 0x0000000000000008 0x0000000000000018 .symtab
We can see the .text section has an address of 0x00000137f1030000, but in LLDB it gets set to zero:
(lldb) image dump sections
Dumping sections for 1 modules.
Sections for ‘/tmp/ELFData.txt’ (x86_64):
SectID Type File Address Perm File Off. File Size Flags Section Name
0x00000001 regular — 0x000004c0 0x000000a1 0x00000000 ELFData.txt…strtab
0x00000002 code [0x0000000000000000-0x000000000000002a) r-x 0x00000040 0x0000002a 0x00000006 ELFData.txt…text
0x00000003 dwarf-str — 0x0000006a 0x0000003e 0x00000030 ELFData.txt…debug_str
0x00000004 dwarf-abbrev — 0x000000a8 0x00000043 0x00000000 ELFData.txt…debug_abbrev
0x00000005 dwarf-info — 0x000000eb 0x0000008d 0x00000000 ELFData.txt…debug_info
0x00000006 elf-relocation-entries — 0x00000310 0x00000150 0x00000000 ELFData.txt…rela.debug_info
0x00000007 dwarf-pubnames — 0x00000178 0x0000001c 0x00000000 ELFData.txt…debug_pubnames
0x00000008 elf-relocation-entries — 0x00000460 0x00000018 0x00000000 ELFData.txt…rela.debug_pubnames
0x00000009 dwarf-pubtypes — 0x00000194 0x00000026 0x00000000 ELFData.txt…debug_pubtypes
0x0000000a elf-relocation-entries — 0x00000478 0x00000018 0x00000000 ELFData.txt…rela.debug_pubtypes
0x0000000b regular — 0x000001ba 0x00000000 0x00000000 ELFData.txt…note.GNU-stack
0x0000000c eh-frame [0x0000000000000030-0x0000000000000068) r-- 0x000001c0 0x00000038 0x00000002 ELFData.txt…eh_frame
0x0000000d elf-relocation-entries — 0x00000490 0x00000018 0x00000000 ELFData.txt…rela.eh_frame
0x0000000e dwarf-line — 0x000001f8 0x00000052 0x00000000 ELFData.txt…debug_line
0x0000000f elf-relocation-entries — 0x000004a8 0x00000018 0x00000000 ELFData.txt…rela.debug_line
0x00000010 elf-symbol-table — 0x00000250 0x000000c0 0x00000000 ELFData.txt…symtab
So I am not sure if this is due to the program header changes in LLDB, or due to the fact that this file is basically a .o file with relocations (the ELF header shows the e_type is ET_REL).
If you have an older LLDB that did work, it would be interesting to load this ELF file into that LLDB and see what the “image dump sections” looks like.