[lldb-dev] lldb10 can not hit break point on windows platform
le wang via lldb-dev
lldb-dev at lists.llvm.org
Tue Oct 20 22:02:13 PDT 2020
Thanks, I will take a look.
Greg Clayton <clayborg at 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 <wangle8816 at 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 <clayborg at 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 at 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 at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> <ELFData.txt><TestFunction.cpp>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20201021/d74bf408/attachment-0001.html>
More information about the lldb-dev
mailing list