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
I agree with Pavel about the larger picture - we need to know the driver behind
address spaces before we can discuss a workable solution.
I've dealt with 2 use cases - Harvard architecture cores, and low level
hardware debugging.
A Harvard architecture core has separate instruction and data mem
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 h
There's a lot of things that are unclear to me about this proposal. The
mechanics of representing an segmented address are one thing, but I I
think that the really interesting part will be the interaction with the
rest of lldb. Like
- What's going to be the source of this address space informati
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 c
