[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 00:54:54 PDT 2020
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20201020/ffd9160f/attachment.html>
-------------- next part --------------
ELF > h @ @ H���D$ �D$ �D$ H�D$ H��� . E:/test/TestFunction.cpp E:/test 20000 k int32 i m n int64 %�B�B .@? 4 : ; I $ > � * * W � ~ � ~ � ~ � � � 2 20000 " � ~ int32 � int64 zR x � * D N 0 �
E:/test TestFunction.cpp
K��� � �� � *
& 3 A
$ I
* W
2 e
4 s
6
, �
8
= .debug_abbrev .text .rela.debug_pubtypes .rela.debug_pubnames .debug_str .rela.debug_info .note.GNU-stack .rela.debug_line .rela.eh_frame .strtab .symtab 20000 � � � �7 @ * ? 0 j > � C O � � J P / x * ` � & x [ � � p �7 � 8 | � p � R k � � P �
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestFunction.cpp
Type: application/octet-stream
Size: 112 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20201020/ffd9160f/attachment.obj>
More information about the lldb-dev
mailing list