Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

2017-12-22 Thread Pavel Labath via lldb-dev 
On 21 December 2017 at 16:22, Greg Clayton  wrote:
>
>
> The main idea is to touch as few pages as possible when doing searches. We
> effectively have this scenario right now with Apple DWARF in .o file
> debugging. So much time is spent paging in each accelerator table that we
> have very long delays starting up large apps. This would be more localized,
> but there would be a similar issue. Concatenation would be fine for now if
> we make it work, but for long term archival, the real solution is to merge
> the tables.

I think we should get better performance from concatenated tables than
from the .o file search on darwin -- the proximity (on disk and
in-memory) should make the os read-ahead work much better than when
the individual tables are scattered in various throughout the disk.

If we're talking about the scenario of archiving debug info on
buildservers or whereever, then something like dsymutil definitely
makes sense. The scenario I am optimizing for though is the
edit-compile-debug cycle of binaries built on your local machine.
There it doesn't matter much whether the indexing is done in the
debugger or the compiler, it just needs to be done quickly.

> We could save this information to disk. I would suggest our Apple Accelerator 
> table format! hahaha.

Yes, that would certainly make sense. :)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 35671] Debugserver does not propagate environment when launching with a pre-loaded inferior

2017-12-22 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=35671

lab...@google.com changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)||321355
 OS|Linux   |MacOS X
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Question about LLVMCDisassembler

2017-12-22 Thread Tatyana Krasnukha via lldb-dev 
Hello,

Could someone answer two questions about this code, please
DisassemblerLLVMC::LLVMCDisassembler::LLVMCDisassembler starting from line 897:

  m_reg_info_ap.reset(curr_target->createMCRegInfo(triple));

  m_subtarget_info_ap.reset(
  curr_target->createMCSubtargetInfo(triple, cpu, features_str));

  std::unique_ptr reg_info(
  curr_target->createMCRegInfo(triple));
  m_asm_info_ap.reset(curr_target->createMCAsmInfo(*reg_info, triple));


  1.  Why it cannot reuse m_reg_info_ap  for createMCAsmInfo instead of 
creation reg_info again?
  2.  It seems that createMCRegInfo can return nullptr. Is it safe to 
dereference reg_info in createMCAsmInfo (line 904)?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev