<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">So the good news is the DWARF seems to be valid.<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">PT_LOAD[0]<br class=""> .note.android.ident<br class=""> .note.gnu.build-id<br class=""> .dynsym<br class=""> .gnu.version<br class=""> .gnu.version_r<br class=""> .gnu.hash<br class=""> .hash<br class=""> .dynstr<br class=""> .rel.dyn<br class=""> .ARM.exidx<br class=""> .rel.plt<br class=""> .ARM.extab<br class=""> .rodata<br class=""> .text<br class=""> .plt<br class="">PT_LOAD[1]<br class=""> .fini_array<br class=""> .<a href="http://data.rel.ro" class="">data.rel.ro</a><br class=""> .dynamic<br class=""> .got<br class=""> .got.plt<br class="">PT_LOAD[2]<br class=""> .data<br class=""> .bss<br class="">.comment<br class="">.ARM.attributes<br class="">.debug_str<br class="">.debug_loc<br class="">.debug_abbrev<br class="">.debug_info<br class="">.debug_ranges<br class="">.debug_macinfo<br class="">.debug_frame<br class="">.debug_line<br class="">.debug_aranges<br class="">.symtab<br class="">.shstrtab<br class="">.strtab<br class=""><br class=""></div><div class=""><div class="">Note how any section that is contained within a program header is contained within a PT_LOAD[N] section.</div><div class=""><br class=""></div><div class="">If I load your ELF binary, I can set a breakpoint:</div><div class=""><br class=""></div><div class="">(lldb) b TestFunction.cpp:1<br class="">Breakpoint 1: where = ELFData.txt`::20000() + 4 at TestFunction.cpp:1:7, address = 0x0000000000000004</div><div class=""><br class=""></div><div class="">I can also view the line table that LLDB was able to parse:</div><div class=""><br class=""></div><div class=""><br class="">(lldb) target modules dump line-table TestFunction.cpp<br class="">Line table for /test/E:/test/TestFunction.cpp in `ELFData.txt<br class="">0x0000000000000000: E:/test/TestFunction.cpp<br class="">0x0000000000000004: E:/test/TestFunction.cpp:1:7<br class="">0x000000000000000c: E:/test/TestFunction.cpp:2:7<br class="">0x0000000000000014: E:/test/TestFunction.cpp:3:7<br class="">0x000000000000001c: E:/test/TestFunction.cpp:4:7<br class="">0x000000000000002a: E:/test/TestFunction.cpp:4:7<br class=""><br class="">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:</div><div class=""><br class=""></div><div class="">$ elf.py /tmp/ELFData.txt <br class="">ELF: /tmp/ELFData.txt (x86_64)<br class="">ELF Header:<br class="">e_ident[EI_MAG0 ] = 0x7f<br class="">e_ident[EI_MAG1 ] = 0x45 'E'<br class="">e_ident[EI_MAG2 ] = 0x4c 'L'<br class="">e_ident[EI_MAG3 ] = 0x46 'F'<br class="">e_ident[EI_CLASS ] = 0x02 ELFCLASS64<br class="">e_ident[EI_DATA ] = 0x01 ELFDATA2LSB<br class="">e_ident[EI_VERSION ] = 0x01<br class="">e_ident[EI_OSABI ] = 0x00 ELFOSABI_NONE<br class="">e_ident[EI_ABIVERSION] = 0x00<br class="">e_type = 0x0001 ET_REL<br class="">e_machine = 0x003e EM_X86_64<br class="">e_version = 0x00000001<br class="">e_entry = 0x0000000000000000<br class="">e_phoff = 0x0000000000000000<br class="">e_shoff = 0x0000000000000568<br class="">e_flags = 0x00000000<br class="">e_ehsize = 0x0040<br class="">e_phentsize = 0x0000<br class="">e_phnum = 0x0000<br class="">e_shentsize = 0x0040<br class="">e_shnum = 0x0011<br class="">e_shstrndx = 0x0001<br class=""><br class=""><br class="">Section Headers:<br class="">Index sh_name sh_type sh_flags sh_addr sh_offset sh_size sh_link sh_info sh_addr_a sh_entsize<br class="">======= ---------- ----------------- ------------------ ------------------ ------------------ ------------------ ---------- ---------- ------------------ ------------------<br class="">[ 0] 0x00000000 SHT_NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000 0x00000000 0x0000000000000000 0x0000000000000000 <br class="">[ 1] 0x0000008b SHT_STRTAB 0x0000000000000000 0x0000000000000000 0x00000000000004c0 0x00000000000000a1 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .strtab<br class="">[ 2] 0x0000000f SHT_PROGBITS 0x0000000000000006 0x00000137f1030000 0x0000000000000040 0x000000000000002a 0x00000000 0x00000000 0x0000000000000010 0x0000000000000000 .text ( SHF_ALLOC SHF_EXECINSTR )<br class="">[ 3] 0x0000003f SHT_PROGBITS 0x0000000000000030 0x0000000000000000 0x000000000000006a 0x000000000000003e 0x00000000 0x00000000 0x0000000000000001 0x0000000000000001 .debug_str ( SHF_MERGE SHF_STRINGS )<br class="">[ 4] 0x00000001 SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000000a8 0x0000000000000043 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_abbrev<br class="">[ 5] 0x0000004f SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000000eb 0x000000000000008d 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_info<br class="">[ 6] 0x0000004a SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000310 0x0000000000000150 0x00000010 0x00000005 0x0000000000000008 0x0000000000000018 .rela.debug_info<br class="">[ 7] 0x0000002f SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x0000000000000178 0x000000000000001c 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_pubnames<br class="">[ 8] 0x0000002a SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000460 0x0000000000000018 0x00000010 0x00000007 0x0000000000000008 0x0000000000000018 .rela.debug_pubnames<br class="">[ 9] 0x0000001a SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x0000000000000194 0x0000000000000026 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_pubtypes<br class="">[ 10] 0x00000015 SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000478 0x0000000000000018 0x00000010 0x00000009 0x0000000000000008 0x0000000000000018 .rela.debug_pubtypes<br class="">[ 11] 0x0000005b SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000001ba 0x0000000000000000 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .note.GNU-stack<br class="">[ 12] 0x00000081 SHT_ARM_EXIDX 0x0000000000000002 0x00000137f1040000 0x00000000000001c0 0x0000000000000038 0x00000000 0x00000000 0x0000000000000008 0x0000000000000000 .eh_frame ( SHF_ALLOC )<br class="">[ 13] 0x0000007c SHT_RELA 0x0000000000000000 0x0000000000000000 0x0000000000000490 0x0000000000000018 0x00000010 0x0000000c 0x0000000000000008 0x0000000000000018 .rela.eh_frame<br class="">[ 14] 0x00000070 SHT_PROGBITS 0x0000000000000000 0x0000000000000000 0x00000000000001f8 0x0000000000000052 0x00000000 0x00000000 0x0000000000000001 0x0000000000000000 .debug_line<br class="">[ 15] 0x0000006b SHT_RELA 0x0000000000000000 0x0000000000000000 0x00000000000004a8 0x0000000000000018 0x00000010 0x0000000e 0x0000000000000008 0x0000000000000018 .rela.debug_line<br class="">[ 16] 0x00000093 SHT_SYMTAB 0x0000000000000000 0x0000000000000000 0x0000000000000250 0x00000000000000c0 0x00000001 0x00000007 0x0000000000000008 0x0000000000000018 .symtab<br class=""><br class=""><br class="">We can see the .text section has an address of 0x00000137f1030000, but in LLDB it gets set to zero:</div><div class=""><br class="">(lldb) image dump sections<br class="">Dumping sections for 1 modules.<br class="">Sections for '/tmp/ELFData.txt' (x86_64):<br class=""> SectID Type File Address Perm File Off. File Size Flags Section Name<br class=""> ---------- ---------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------<br class=""> 0x00000001 regular --- 0x000004c0 0x000000a1 0x00000000 ELFData.txt..strtab<br class=""> 0x00000002 code [0x0000000000000000-0x000000000000002a) r-x 0x00000040 0x0000002a 0x00000006 ELFData.txt..text<br class=""> 0x00000003 dwarf-str --- 0x0000006a 0x0000003e 0x00000030 ELFData.txt..debug_str<br class=""> 0x00000004 dwarf-abbrev --- 0x000000a8 0x00000043 0x00000000 ELFData.txt..debug_abbrev<br class=""> 0x00000005 dwarf-info --- 0x000000eb 0x0000008d 0x00000000 ELFData.txt..debug_info<br class=""> 0x00000006 elf-relocation-entries --- 0x00000310 0x00000150 0x00000000 ELFData.txt..rela.debug_info<br class=""> 0x00000007 dwarf-pubnames --- 0x00000178 0x0000001c 0x00000000 ELFData.txt..debug_pubnames<br class=""> 0x00000008 elf-relocation-entries --- 0x00000460 0x00000018 0x00000000 ELFData.txt..rela.debug_pubnames<br class=""> 0x00000009 dwarf-pubtypes --- 0x00000194 0x00000026 0x00000000 ELFData.txt..debug_pubtypes<br class=""> 0x0000000a elf-relocation-entries --- 0x00000478 0x00000018 0x00000000 ELFData.txt..rela.debug_pubtypes<br class=""> 0x0000000b regular --- 0x000001ba 0x00000000 0x00000000 ELFData.txt..note.GNU-stack<br class=""> 0x0000000c eh-frame [0x0000000000000030-0x0000000000000068) r-- 0x000001c0 0x00000038 0x00000002 ELFData.txt..eh_frame<br class=""> 0x0000000d elf-relocation-entries --- 0x00000490 0x00000018 0x00000000 ELFData.txt..rela.eh_frame<br class=""> 0x0000000e dwarf-line --- 0x000001f8 0x00000052 0x00000000 ELFData.txt..debug_line<br class=""> 0x0000000f elf-relocation-entries --- 0x000004a8 0x00000018 0x00000000 ELFData.txt..rela.debug_line<br class=""> 0x00000010 elf-symbol-table --- 0x00000250 0x000000c0 0x00000000 ELFData.txt..symtab<br class=""><br class=""></div><div class=""><div><br class=""></div><div>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).</div><div><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Oct 20, 2020, at 12:54 AM, le wang <<a href="mailto:wangle8816@gmail.com" class="">wangle8816@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""> Hi, all:</div><div class=""> Thanks for your answer. Maybe my description is not clear enough. MLExecuteTest.exe is just a shell to compile and execute TestFunctin.cpp, the step is below: </div><div class=""> 1. call llvm function to compile TestFunction.cpp, this will create module ,function, block, instruction, and generate binary code with debug info;</div><div class=""> 2. it uses JIT ExecuteEnginie to execute the binary code.</div><div class=""> and what I use lldb to debug is the binary code generated from TestFunction.cpp. So I am not concerned about the pdb of MLExecuteTest.exe.</div><div class=""> </div><div class=""> According to your suggestion, I have debug lldb source code, set breakpoint in SymbolFilePDB::ResolveSymbolContext, but not come in this function. Since I think my debug info is all generated by llvm tegother with IR in the first phrase, which is all contained in binary code. I don't know in the second phrase, while JIT load binary code to generate execute process, weather JIT will meanwhile generate some other debug info in PDB forms on windows platform, if so, which library in llvm do this work, and how does lldb load these PDB symbols. Because if PDB needs to be generated, maybe this is what I missed. </div><div class=""> </div><div class=""> On the other hand, I've debug the lldb to see what happens in CompileUnit::ResolveSymbolContext, and found that every debug line can be parsed from DWARFDebugLine.cpp, then the function FindLineEntryIndexByFileIndex in LinTable.cpp will find whether the file_addr of line entry is contained in file addresses of section list(I don't know the reason why lldb do this). But the result is the file_addr of each line can not be found from the section list addresses. So at last lines are not found, breakpoint not hit.</div><div class=""><br class=""></div><div class=""> I have added some code in notifyObjectLoaded function from GDBRegistrationListener.cpp to store the middle ELF data. Sections and debug_line details can be seen by the readelf linux command. Can you help me to analyse the debug info in ELF, check whether there is anything wrong in debug info, which causes breakpoints not to be hit. </div><div class=""><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the TestFunction.cpp and its ELF data is brought in attachment.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">le wang</div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> 于2020年10月20日周二 上午7:23写道：<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As long as the location TestFunction.cpp:1 has a valid line in the PDB line tables, this breakpoint should be hit if there is debug info and the internal PDB parser is parsing things correctly. If you have debug info in your binary, _and_ if LLDB is able to locate your PDB file, then you should end up seeing a location if it was found. We can see this isn't happening:<br class="">
<br class="">
(lldb）br s -fE:/test/TestFunction.cpp -l1<br class="">
Breakpoint 1: no locations(pending).<br class="">
WARNING : Unable to resolve breakpoint to any actual locations.<br class="">
<br class="">
I would suggest debugging the LLDB and debugging:<br class="">
<br class="">
uint32_t SymbolFilePDB::ResolveSymbolContext(const lldb_private::FileSpec &file_spec, uint32_t line, bool check_inlines, SymbolContextItem resolve_scope, lldb_private::SymbolContextList &sc_list);<br class="">
<br class="">
This function is what turns the file (in "file_spec") and line (in "line") into a symbol context list (in "sc_list"). A SymbolContext is a class that defines a complete symbol file context for something. It contains a Module (executable), CompileUnit (if there is debug info for the source file), Function (if there is debug info for the function), Block (lexical block of the deepest lexical block that contains the start address for the file + line), LineEntry (source file and line number, which might have a line number greater than what you requested if there was no perfect match), and Symbol (symbol from the symbol table). We have a symbol context list, because you might have multiple matches for a given source file and line if your functions was inlined.<br class="">
<br class="">
You might try just doing:<br class="">
<br class="">
(lldb) b TestFunction.cpp:1<br class="">
<br class="">
And seeing if that helps. If the debug information doesn't contain the exact same path of "E:/test/TestFunction.cpp", it might not set the breapoint if the path in the debug info contains symlinks or is a relative path.<br class="">
<br class="">
Does anyone know if the "pdb" file shows up when doing "image list" in LLDB? On mac if we have a stand alone debug info file, we show it below the executable:<br class="">
<br class="">
(lldb) target create "/tmp/a.out"<br class="">
Current executable set to '/tmp/a.out' (x86_64).<br class="">
(lldb) image list a.out<br class="">
[ 0] E76A2647-AFB4-3950-943A-CB1D701B7C07 0x0000000100000000 /tmp/a.out <br class="">
/tmp/a.out.dSYM/Contents/Resources/DWARF/a.out<br class="">
<br class="">
<br class="">
If you do a "image list" on your executable, it would be interesting to see if the pdb file shows up in this output.<br class="">
<br class="">
Greg Clayton<br class="">
<br class="">
> On Oct 17, 2020, at 1:51 AM, le wang via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:<br class="">
> <br class="">
> Hello,everyone:<br class="">
> I have a problem when download llvm10.0.1 and use lldb to debug my process on windows10 x64 platform. but with no debug point hit.<br class="">
> the command is<br class="">
> （lldb）target create "D:/code/MLExecuteTest.exe"<br class="">
> Current executable set to 'D:/code/MLExecuteTest.exe' (x86_64) <br class="">
> （lldb）br s -fE:/test/TestFunction.cpp -l1<br class="">
> Breakpoint 1: no locations(pending).<br class="">
> WARNING : Unable to resolve breakpoint to any actual locations.<br class="">
> （lldb）r<br class="">
> Process 16228 launched 'D:/code/MLExecuteTest.exe'<br class="">
> Process 16228 exited with status = 1(0x00000001)<br class="">
> my using detail is this below:<br class="">
> MLExecuteTest.exe is my process which will first compile the script TestFunction.cpp on debug mode and generate binary code in its memory, of course binary code has debug information, and then it use JIT ExecuteEngine to execute the binary code. I want to know, is llvm 10.0.1 support this using on windows platform. since before we use llvm5.0 on windows platform is OK, breakpoints can be hit. but while update version to 10.0.1, with same operation ,breakpoints can not be hit. so is llvm10.0.1 support or has any changes on this using on windows platform? <br class="">
> <br class="">
> Thanks,<br class="">
> le wang<br class="">
> _______________________________________________<br class="">
> lldb-dev mailing list<br class="">
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a><br class="">
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="">
<br class="">
</blockquote></div>
<span id="cid:f_kgho8lnt0"><ELFData.txt></span><span id="cid:f_kgho8v4y1"><TestFunction.cpp></span></div></blockquote></div><br class=""></div></div></body></html>