Thanks, I will take a look. Greg Clayton <clayb...@gmail.com> 于2020年10月21日周三 上午2:50写道：
> 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. > > > On Oct 20, 2020, at 12:54 AM, le wang <wangle8...@gmail.com> wrote: > > Hi, all: > 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: > 1. call llvm function to compile TestFunction.cpp, this will create > module ,function, block, instruction, and generate binary code with debug > info; > 2. it uses JIT ExecuteEnginie to execute the binary code. > 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. > > 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. > > 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. > > 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. > the TestFunction.cpp and its ELF data is brought in attachment. > > Thanks, > le wang > > Greg Clayton <clayb...@gmail.com> 于2020年10月20日周二 上午7:23写道： > >> 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: >> >> (lldb）br s -fE:/test/TestFunction.cpp -l1 >> Breakpoint 1: no locations(pending). >> WARNING : Unable to resolve breakpoint to any actual locations. >> >> I would suggest debugging the LLDB and debugging: >> >> uint32_t SymbolFilePDB::ResolveSymbolContext(const lldb_private::FileSpec >> &file_spec, uint32_t line, bool check_inlines, SymbolContextItem >> resolve_scope, lldb_private::SymbolContextList &sc_list); >> >> 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. >> >> You might try just doing: >> >> (lldb) b TestFunction.cpp:1 >> >> 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. >> >> 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: >> >> (lldb) target create "/tmp/a.out" >> Current executable set to '/tmp/a.out' (x86_64). >> (lldb) image list a.out >> [ 0] E76A2647-AFB4-3950-943A-CB1D701B7C07 0x0000000100000000 /tmp/a.out >> /tmp/a.out.dSYM/Contents/Resources/DWARF/a.out >> >> >> If you do a "image list" on your executable, it would be interesting to >> see if the pdb file shows up in this output. >> >> Greg Clayton >> >> > On Oct 17, 2020, at 1:51 AM, le wang via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > >> > Hello,everyone: >> > 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. >> > the command is >> > （lldb）target create "D:/code/MLExecuteTest.exe" >> > Current executable set to 'D:/code/MLExecuteTest.exe' (x86_64) >> > （lldb）br s -fE:/test/TestFunction.cpp -l1 >> > Breakpoint 1: no locations(pending). >> > WARNING : Unable to resolve breakpoint to any actual locations. >> > （lldb）r >> > Process 16228 launched 'D:/code/MLExecuteTest.exe' >> > Process 16228 exited with status = 1(0x00000001) >> > my using detail is this below: >> > 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? >> > >> > Thanks, >> > le wang >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> <ELFData.txt><TestFunction.cpp> > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
