labath added a comment.
In https://reviews.llvm.org/D42955#1026216, @clayborg wrote:
> AS for the ELF example where only debug info is around, it might not be
> running into issues if it doesn't contain a symbol table. If it does contain
> a symbol table, hopefully it is using the unified section table, otherwise if
> might have symbol's whose addresses have sections from the stripped ELF file
> and it might not have the section contents that it needs to back it. In that
> case we might fail to disassemble the symbol's code.
I made a trivial experiment:
objcopy a.out --only-keep-debug a.sym #a.sym contains a symtab
strip a.out # a.out does not contain a symtab
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) target symbols add a.sym
symbol file '/tmp/X/a.sym' has been added to '/tmp/X/a.out'
1 location added to breakpoint 1
#symbol resolution seems fine
(lldb) disassemble -n main
a.out[0x69b] <+0>: pushq %rbp
a.out[0x69c] <+1>: movq %rsp, %rbp
a.out[0x69f] <+4>: callq 0x690 ; foo()
a.out[0x6a4] <+9>: addl $0x2a, %eax
a.out[0x6a7] <+12>: popq %rbp
a.out[0x6a8] <+13>: retq
# so does disassembling
The part that is not clear to me is, if the dsym object file should absorb the
sections from the main object file, then what is the purpose of the "unified
section list" in the module? I can see why we need a unified list, and I think
it's a good idea, but having an ObjectFile containing the merged list seems to
defeat it. From a separation of concerns POV, it would be much clearer if each
ObjectFile contained only it's own sections, and then some other entity
(Module) held the combined data(sections) of the individual object files. Then,
most clients should operate on the unified view of the module, but if anyone
ever had a reason, he could always look directly at a specific ObjectFile, and
see what's contained there.
Among other things, this could be very useful for lldb-server. lldb-server
needs only lightweight access to the data in the object file -- it does not
need the Module class and everything it pulls in (SymbolVendor, SymbolFile,
...). If we could make the ObjectFile class completely standalone, we can avoid
pulling all this stuff in and make the code more modular. It would also help
with the migration to llvm's Object parsing library, as it knows nothing about
unified sections. If we had a standalone ObjectFile implementation, then it
would be easy to swap it out for llvm's and still keep the "section
unification" code intact as it would be in a different layer.
So, could this be a direction we can move in? I can put this patch on ice and
try to make the ObjectFileMachO standalone instead. I don't think it should be
that hard, given that this is how things already work for elf. I'm hoping it
will be a matter of changing some consumers to use module->GetSectionList()
instead of objfile->GetSectionList()...
lldb-commits mailing list