[lldb-dev] LLDB's disassemble function

Ted Woodward via lldb-dev lldb-dev at lists.llvm.org
Fri Jul 31 08:48:38 PDT 2020


Hi Rui,

Disassembler::Disassemble calls ParseInstructions with prefer_file_cache set to false. Try setting prefer_file_cache to true.

Ted

From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Rui Hong via lldb-dev
Sent: Thursday, July 30, 2020 10:08 PM
To: lldb-dev <lldb-dev at lists.llvm.org>
Subject: [EXT] [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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200731/fce781a5/attachment-0001.html>


More information about the lldb-dev mailing list