[lldb-dev] LLDB problem about building with Python
Hi LLDB devs, I'm working on porting LLDB to my own architecture. I choose to use the target-definition-file(python) to let LLDB support my architecture based on my situation(already have a workable GDB-stub and the target is an embedded DSP). The usage: (lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/_target_definition.py (lldb) gdb-remote So I think I definitely need to rebuild LLDB with python support(cmake with -DLLDB_ENABLE_PYTHON=1 according to https://lldb.llvm.org/resources/build.html). But problem comes: getting this error: CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: /export/pfs/home/lte_dsp/hongrui/DEBUG/jihai_lldb/jihai_lldb/lldb/scripts/Python/modules/readline/libedit_INCLUDE_DIRS used as include directory in directory /export/pfs/home/lte_dsp/hongrui/DEBUG/jihai_lldb/jihai_lldb/lldb/scripts/Python/modules/readline libedit_LIBRARIES (ADVANCED) linked by target "readline" in directory /export/pfs/home/lte_dsp/hongrui/DEBUG/jihai_lldb/jihai_lldb/lldb/scripts/Python/modules/readline This problem persists even after I add -DLLDB_ENABLE_LIBEDIT=0 My cmake version is 3.5.2, the LLDB/LLVM version I choose to work with is 7.0.1 My complete command is: cmake -G "Unix Makefiles" -DLLDB_ENABLE_LIBEDIT=0 -DLLDB_ENABLE_PYTHON=1 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib64/libpython2.7.so.1.0 -DLLVM_TARGETS_TO_BUILD=JiHai -DLLVM_ENABLE_PROJECTS='lldb' -DLLDB_EXPORT_ALL_SYMBOLS=1 -DCMAKE_BUILD _TYPE=Debug -DCMAKE_INSTALL_PREFIX=. ../llvm make -j 8 Why the error persists even with -DLLDB_ENABLE_LIBEDIT=0? Does this mean that LLDB python support also need libedit? And what should I do to make LLDB_build_with_python correct(I just want to use the target-definition-file)? Kind regards, Rui___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB problem with TAB
Hi LLDB devs, First I want to thank you all for the very helpful advice on my former question! It's a really nice community. I have a small problem now about LLDB tab completion and I haven't found any solutions so far. I used to have nice tab completion before. But I cannot get this feature to work on my LLDB 7.0.1 on linux after I enable python, where an actual tab is inserted after the cursor and similar for other control characters like Backspace. Both in lldb console and the embedded python interpreter?? That's very inconvenient. Is there anything wrong? I haven't changed the code at all, just added some necessary parameters in cmake command to enable python. Things worked well even last week before rebuild with python Kind regards, Rui___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB problems on remote debugging
Hi LLDB devs, I'm working on porting LLDB to work with an existing simulator(which has GDB stub, remote debugging). This simulator used to work with GDB. When using with GDB, the target file(ELF) is loaded by GDB command "load" or "remote put". From a LLVM talk project which is very similar to my project, their target file is loaded by the simulator itself( ./sim a.out , something like that), and lldb sets breakpoint, use "gdb-remote" command to connect to the simulator, the program starts to run immediately and stop at the breakpoint. I can't find any lldb command that is equal to "load" in GDB. And right now when I use "gdb-remote" to connect lldb to my simulator, lldb has command line output "Process 10115 stopped??thread #1, stop reason = signal SIGTRAP??frame #0: 0x". Does this mean the program has already started to run? I haven't loaded the binary. To sum my questions: 1. Does lldb has similar command like "load/remote put" in GDB? 2. Does "gdb-remote" command in lldb do the "loading binary" job? 3. Will the program start to run immediately after "gdb-remote" command in lldb? 4. Do I have to let my simulator to load the binary by itself? Kind regards, Rui___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB problems on remote debugging
Hi LLDB devs, First I would like to express my appreciation and thanks to you all especially Greg Clayton and Ted Woodward! Your advice and guidance are quite useful for me! I've been working on other lldb problems and resume solving the "remote loading" issue now. I now fully understand the "remote connection/execution"(what happens after gdb-remote and how 'c' or 's' controls the execution) and the only problem is how to load the program. My simulator starts this way : ./sim --port 1234 It do not do the "loading program" job when specified with --port right now. In order to fit the old GDB style, I prefer to still let lldb to do the "loading binary" job. To provide more information about my memory architecture : logically, the memory is a whole(one address space), but divided into PM(program memory, starting at address 0x0) and DM(data memory, starting at address 0x8000). When loading program, the .text section should be loaded into PM and the .data section should be loaded into DM, and nothing more. And yes, only one executable. I've tried "target modules load --load"(I'm using lldb 7.0.1 and it implemented this command), but the sections to load are not loadable(not PT_LOAD) and triggers no RSP package exchange. So I tried "memory write --infile", it triggers a "qMemoryRegionInfo:0" packet to query memory region info and a "M" packet to write memory, but these two packet are not supported by my simulator right now. My simulator supports "X" packet not "M"! When using with the old GDB, "load" command in GDB triggers a few "X" packets So I want to know: 1. How to let lldb send "X" packet(perhaps a command) and where is the corresponding code located?(to let my simulator support "M" packet is also OK, but using the existing code that handles "X" packet is much easier) 2. What's the actual difference between "X" packet and "M" packet?(I can't see any difference between them, from the packet specification on GDB website. "X" packet is "X addr,length:XX??" and "M" packet is "M addr,length:XX??", I thought even the data "XX??" seems to be encoded in the same way: two hexadecimal digits per byte, or perhaps I was wrong?) 3. Is letting my simulator support "qMemoryRegionInfo" packet enough to make lldb send the correct "X" or "M" packets?(extract .text and .data sections from my executable and send them to PM and DM addresses) *4. by the way, does GDB has similar command like "log enable gdb-remote packets" in lldb to print all the RSP packet exchange? Kind regards, Rui -- Original -- From: "Greg Clayton"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] LLDB's disassemble function
Hi LLDB devs, I have almost finished porting LLDB to my architecture, now LLDB communicates well with my GDB stub of my simulator and can do debugging actions like breakpoint, continue, step, reading memory, reading registers and so on. Thanks to all of your kind advice~ Now I consider adding disassemble function. Our compiler is LLVM(of course after porting it to our new architecture) and a LLVM disassembler has already been implemented, which can do great objdump from the ELF file that LLVM generates, creating a .map file containing disassemble. LLDB leverages the disassembler from LLVM, so our LLDB can easily use that disassembler plug-in. Here comes problems: I found that when LLDB deals with command "disassemble/dis/di", it would detect the current frame, confirm the disassemble address range, send a "m" packet to read the corresponding memory to get the program, and use LLVM disassembler plug-in to disassemble the code, which I would like to call it "dynamic disassembling". But in our architecture, program and data are in separated memory which have the same address space. When reading memory, we just read the data memory not the program memory, in other words, program/code cannot be accessed from processor, only from ELF file(program/code won't be altered during run time, we use hardware breakpoint). So: Can LLDB do "static disassembling"? (which just uses program/code from the ELF executable file without reading memory from the processor during run time) Kind regards, Rui___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
