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: g++ a.cc 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`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()... https://reviews.llvm.org/D42955 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
