[Lldb-commits] [PATCH] D42955: Make Module::GetSectionList output consistent

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D42955#1026296, @labath wrote:

> 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.


The issue is the object file must create symbols that uses the section from the unified section list. The easiest way to accomplish that was to have the object file just use the right section and not have to worry about any other code having to know anything about the relationship between a debuig info file and the main executable file.

> 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()...

Again, we need any objects coming out of the ObjectFile to have the correct sections. Not sure how we would accomplish that with a solution where the dSYM file uses it own useless sections.


https://reviews.llvm.org/D42955