labath added a comment.

In, @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

Reply via email to