Re: [lldb-dev] lldb10 can not hit break point on windows platform
Thanks, I will take a look. Greg Clayton 于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`::2() + 4 at TestFunction.cpp:1:7, > address = 0x0004 > > 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 > 0x: E:/test/TestFunction.cpp > 0x0004: E:/test/TestFunction.cpp:1:7 > 0x000c: E:/test/TestFunction.cpp:2:7 > 0x0014: E:/test/TestFunction.cpp:3:7 > 0x001c: E:/test/TestFunction.cpp:4:7 > 0x002a: 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 = 0x0001 > e_entry = 0x > e_phoff = 0x > e_shoff = 0x0568 > e_flags = 0x > e_ehsize= 0x0040 > e_phentsize = 0x > e_phnum = 0x > e_shentsize = 0x0040 > e_shnum = 0x0011 > e_shstrndx = 0x0001 > > > Section Headers: > Index sh_namesh_type sh_flags sh_addr > sh_offset sh_sizesh_linksh_infosh_addr_a > sh_entsize > === -- - -- -- > -- -- -- -- > -- -- > [0] 0x SHT_NULL 0x 0x > 0x 0x 0x 0x > 0x 0x > [1] 0x008b SHT_STRTAB0x 0x > 0x04c0 0x00a1 0x 0x > 0x0001 0x .strtab > [2] 0x000f SHT_PROGBITS 0x0006 0x0137f103 > 0x0040 0x002a 0x 0x > 0x0010 0x .text ( SHF_ALLOC SHF_EXECINSTR ) > [3] 0x003f SHT_PROGBITS 0x0030 0x > 0x006a 0x003e 0x 0x > 0x0001 0x0001 .debug_str ( SHF_MERGE SHF_STRINGS ) > [4] 0x0001 SHT_PROGBITS 0x 0x > 0x00a8 0x0043 0x 0x > 0x0001 0x .debug_abbrev > [5] 0x004f SHT_PROGBITS 0x 0x > 0x00eb 0x008d 0x 0x > 0x0001 0x .debug_info > [6] 0x004a SHT_RELA 0x 0x > 0x0310 0x0150 0x0010 0x0005 > 0x0008 0x0018 .rela.debug_info > [7] 0x002f SHT_PROGBITS 0x 0x > 0x0178 0x001c 0x 0x > 0x0001 0x .debug_pubnames > [8] 0x002a SHT_RELA 0x 0x > 0x0460 0x0018 0x0010 0x0007 > 0x0008 0x0018 .rela.debug_pubnames > [9] 0x001a SHT_PROGBITS 0x 0x > 0x0194 0x0026 0x
Re: [lldb-dev] lldb10 can not hit break point on windows platform
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`::2() + 4 at TestFunction.cpp:1:7, address = 0x0004 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 0x: E:/test/TestFunction.cpp 0x0004: E:/test/TestFunction.cpp:1:7 0x000c: E:/test/TestFunction.cpp:2:7 0x0014: E:/test/TestFunction.cpp:3:7 0x001c: E:/test/TestFunction.cpp:4:7 0x002a: 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 = 0x0001 e_entry = 0x e_phoff = 0x e_shoff = 0x0568 e_flags = 0x e_ehsize= 0x0040 e_phentsize = 0x e_phnum = 0x e_shentsize = 0x0040 e_shnum = 0x0011 e_shstrndx = 0x0001 Section Headers: Index sh_namesh_type sh_flags sh_addr sh_offset sh_sizesh_linksh_infosh_addr_a sh_entsize === -- - -- -- -- -- -- -- -- -- [0] 0x SHT_NULL 0x 0x 0x 0x 0x 0x 0x 0x [1] 0x008b SHT_STRTAB0x 0x 0x04c0 0x00a1 0x 0x 0x0001 0x .strtab [2] 0x000f SHT_PROGBITS 0x0006 0x0137f103 0x0040 0x002a 0x 0x 0x0010 0x .text ( SHF_ALLOC SHF_EXECINSTR ) [3] 0x003f SHT_PROGBITS 0x0030 0x 0x006a 0x003e 0x 0x 0x0001 0x0001 .debug_str ( SHF_MERGE SHF_STRINGS ) [4] 0x0001 SHT_PROGBITS 0x 0x 0x00a8 0x0043 0x 0x 0x0001 0x .debug_abbrev [5] 0x004f SHT_PROGBITS 0x 0x 0x00eb 0x008d 0x 0x 0x0001 0x .debug_info [6] 0x004a SHT_RELA 0x 0x 0x0310 0x0150 0x0010 0x0005 0x0008 0x0018 .rela.debug_info [7] 0x002f SHT_PROGBITS 0x 0x 0x0178 0x001c 0x 0x 0x0001 0x .debug_pubnames [8] 0x002a SHT_RELA 0x 0x 0x0460 0x0018 0x0010 0x0007 0x0008 0x0018 .rela.debug_pubnames [9] 0x001a SHT_PROGBITS 0x 0x 0x0194 0x0026 0x 0x 0x0001 0x .debug_pubtypes [ 10] 0x0015 SHT_RELA 0x 0x 0x0478 0x0018 0x0010 0x0009 0x0008 0x0018 .rela.debug_pubtypes [ 11] 0x005b
Re: [lldb-dev] lldb10 can not hit break point on windows platform
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 于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 > _spec, uint32_t line, bool check_inlines, SymbolContextItem > resolve_scope, lldb_private::SymbolContextList _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 0x0001 /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:
Re: [lldb-dev] lldb10 can not hit break point on windows platform
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 _spec, uint32_t line, bool check_inlines, SymbolContextItem resolve_scope, lldb_private::SymbolContextList _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 0x0001 /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 > 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(0x0001) > 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb10 can not hit break point on windows platform
On Windows, LLVM is migrating to its own debug info reading code (the Native PDB reader) instead of relying on DIA (a Microsoft-provided Windows-only DLL for accessing debug info), so that might explain the difference between the older versions and the current. I don't know enough about LLDB's model to understand how debug info for run-time generated code is handled. Certainly, at the time your transcript shows trying to set the breakpoint, the TestFunction.cpp code hasn't yet been compiled, so it's not a surprise that it cannot resolve the breakpoint at that time. When TestFunction.cpp gets JITted into code, LLDB would have to (1) be informed of the new code, (2) locate the debug info, and (3) try again to resolve the pending breakpoint. For me, there are a lot of unknowns in that sequence, so I cannot say whether it's expected to work in the current version. If the JITted code is "loaded" dynamically the same way a DLL can be, then step 1 should work. But if the JIT code is brought into process memory some other way, then I think it's likely the Windows debugger isn't getting notified and thus cannot do steps 2 and 3. Is it possible to reduce the problem down to a minimal sample program that reproduces the problem and to include it in a bug report? Thanks, Adrian. On Sat, 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(0x0001) > 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 > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb10 can not hit break point on windows platform
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(0x0001) 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
