[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5

2018-08-28 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In https://reviews.llvm.org/D32167#1212783, @jankratochvil wrote:

> Just a ping, that `ConcatenatingDataExtractor` is still not coded, even as 
> some draft patch? Just checking to prevent duplicating some existing work.
>  FYI providing a rebase with few simple conflicts resolved 
> . I had to drop 
> conflicting `lldb.xcodeproj/project.pbxproj` changes there.


I have stalled on this due to performance. Anything I do will ruin the 
performance of 99% of the DWARF consumers for .debug_types which is rarely used 
by our clients. Right now we have one data extractor with only a virtual 
destructor.


https://reviews.llvm.org/D32167



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51208: [DWARF] Fix dwarf5-index-is-used.cpp

2018-08-28 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In https://reviews.llvm.org/D51208#1214743, @dblaikie wrote:

> >> But if LLDB has different performance characteristics, or the default 
> >> should be different for other reasons - I'm fine with that. I think I left 
> >> it on for Apple so as not to mess with their stuff because of the 
> >> MachO/dsym sort of thing that's a bit different from the environments I'm 
> >> looking at.
> > 
> > These are the numbers from my llvm-dev email in June:
> > 
> >> setting a breakpoint on a non-existing function without the use of
> >>  accelerator tables:
> >>  real0m5.554s
> >>  user0m43.764s
> >>  sys 0m6.748s
> >> 
> >> setting a breakpoint on a non-existing function with accelerator tables:
> >>  real0m3.517s
> >>  user0m3.136s
> >>  sys 0m0.376s
> > 
> > This is an extreme case,
>
> What was being tested here? Is it a realistic case (ie: not a pathalogical 
> case with an absurd number of symbols, etc)? Using ELF? Fission or not?
>
> How's it compare to GDB performance, I wonder? Perhaps LLDB hasn't been 
> optimized for the non-indexed case and could be - though that'd still 
> potentially motivate turning on indexes by default for LLDB until someone has 
> a motivation to do any non-indexed performance tuning/improvements.


The performance is huge for large binaries. LLDB doesn't need to manually index 
all DWARF if the accelerator tables are there, it does if they are not. Many 
people complain about the time it takes to index the DWARF, so avoiding will be 
a huge improvement. We have some server binaries that statically link in libc, 
libstdc++ and many other binaries and they are currently 11GB, with over 10GB 
of that being DWARF. It makes debugging with GDB and LLDB unusable when manual 
indexing of all that DWARF is needed. They have .debug_types enabled where they 
can on these binaries, but LTO tends to be the culprit that can't take 
advantage of the .debug_types so the binaries are still huge.

GDB performance is hard to compare to due to the way they import types. They 
import all types in a compile unit at the same time and have 3 layers of 
resolution as they parse. Their indexes, if created by a linker, just say "foo" 
exists in this compile unit somewhere, not the exact DIE offset, so their 
indexes are useful, but they don't help LLDB out as much as the DWARF 5 
versions do.

> 
> 
>> because practically the only thing we are doing is building the symbol 
>> index, but it's nice for demonstrating the amount of work that lldb needs to 
>> do without it. In practice, the ratio will not be this huge most of the 
>> time, because we will usually find some matches, and then will have to do 
>> some extra work, which will add a constant overhead to both sides. However, 
>> this means that the no-accel case will take even longer. I am not sure how 
>> this compares to gdb numbers, but I think the difference here is significant.
>> 
>> Also, I am pretty sure the Apple folks, who afaik are in the process of 
>> switching to debug_names, will want to have them on by default for their 
>> targets (ping @aprantl, @JDevlieghere). I think the cleanest way (and one 
>> that best reflects the reality) to achieve that would be to have `-glldb` 
>> imply `-gpubnames`. As for whether we should emit debug_names for DWARF 5 by 
>> default (-gdwarf-5 => -gpubnames) is a more tricky question, and I don't 
>> have a clear opinion on that (however, @probinson might).
>> 
>> (In either case, I agree that there are circumstances in which having 
>> debug_names is not beneficial, so having a flag to control them is a good 
>> idea).
> 
> *nod* Happy if you want to (or I can) have clang set pubnames on by default 
> when tuning for LLDB, while allowing -gno-pubnames to turn them off. (& maybe 
> we should have another alias for that flag, since debug_names isn't 
> "pubnames", but that's pretty low-priority)

.debug_pubnames and .debug_pubtypes are not useful for LLDB or any debugger in 
general so please don't enable for LLDB. They only include public functions (no 
statics functions for functions in the anonymous namespace) and types. This 
means LLDB ignores these sections and manually indexes the DWARF, just like GDB 
ignores them.

I would vote to enable the DWARF5 accelerator tables for -glldb by default if 
possible.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51208



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r340835 - Use a RAII guard to control access to DisassemblerLLVMC.

2018-08-28 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Tue Aug 28 08:31:01 2018
New Revision: 340835

URL: http://llvm.org/viewvc/llvm-project?rev=340835&view=rev
Log:
Use a RAII guard to control access to DisassemblerLLVMC.

Summary:
This patch replaces the manual lock/unlock calls for gaining exclusive access 
to the disassembler with
a RAII-powered access scope. This should prevent that we somehow skip over 
these trailing Unlock calls
(e.g. with early returns).

We also have a second `GetDisasmToUse` method now that takes an already 
constructed access scope to
prevent deadlocks when we call this from other methods.

Reviewers: #lldb, davide, vsk

Reviewed By: #lldb, davide, vsk

Subscribers: davide, vsk, lldb-commits

Differential Revision: https://reviews.llvm.org/D51319

Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h

Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp?rev=340835&r1=340834&r2=340835&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp Tue Aug 
28 08:31:01 2018
@@ -98,16 +98,15 @@ public:
 
   bool DoesBranch() override {
 if (m_does_branch == eLazyBoolCalculate) {
-  std::shared_ptr disasm_sp(GetDisassembler());
-  if (disasm_sp) {
-disasm_sp->Lock(this, NULL);
+  DisassemblerScope disasm(*this);
+  if (disasm) {
 DataExtractor data;
 if (m_opcode.GetData(data)) {
   bool is_alternate_isa;
   lldb::addr_t pc = m_address.GetFileAddress();
 
   DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-  GetDisasmToUse(is_alternate_isa);
+  GetDisasmToUse(is_alternate_isa, disasm);
   const uint8_t *opcode_data = data.GetDataStart();
   const size_t opcode_data_len = data.GetByteSize();
   llvm::MCInst inst;
@@ -125,7 +124,6 @@ public:
   m_does_branch = eLazyBoolNo;
   }
 }
-disasm_sp->Unlock();
   }
 }
 return m_does_branch == eLazyBoolYes;
@@ -133,16 +131,15 @@ public:
 
   bool HasDelaySlot() override {
 if (m_has_delay_slot == eLazyBoolCalculate) {
-  std::shared_ptr disasm_sp(GetDisassembler());
-  if (disasm_sp) {
-disasm_sp->Lock(this, NULL);
+  DisassemblerScope disasm(*this);
+  if (disasm) {
 DataExtractor data;
 if (m_opcode.GetData(data)) {
   bool is_alternate_isa;
   lldb::addr_t pc = m_address.GetFileAddress();
 
   DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-  GetDisasmToUse(is_alternate_isa);
+  GetDisasmToUse(is_alternate_isa, disasm);
   const uint8_t *opcode_data = data.GetDataStart();
   const size_t opcode_data_len = data.GetByteSize();
   llvm::MCInst inst;
@@ -160,27 +157,14 @@ public:
   m_has_delay_slot = eLazyBoolNo;
   }
 }
-disasm_sp->Unlock();
   }
 }
 return m_has_delay_slot == eLazyBoolYes;
   }
 
   DisassemblerLLVMC::MCDisasmInstance *GetDisasmToUse(bool &is_alternate_isa) {
-is_alternate_isa = false;
-std::shared_ptr disasm_sp(GetDisassembler());
-if (disasm_sp) {
-  if (disasm_sp->m_alternate_disasm_up) {
-const AddressClass address_class = GetAddressClass();
-
-if (address_class == AddressClass::eCodeAlternateISA) {
-  is_alternate_isa = true;
-  return disasm_sp->m_alternate_disasm_up.get();
-}
-  }
-  return disasm_sp->m_disasm_up.get();
-}
-return nullptr;
+DisassemblerScope disasm(*this);
+return GetDisasmToUse(is_alternate_isa, disasm);
   }
 
   size_t Decode(const lldb_private::Disassembler &disassembler,
@@ -189,9 +173,9 @@ public:
 // All we have to do is read the opcode which can be easy for some
 // architectures
 bool got_op = false;
-std::shared_ptr disasm_sp(GetDisassembler());
-if (disasm_sp) {
-  const ArchSpec &arch = disasm_sp->GetArchitecture();
+DisassemblerScope disasm(*this);
+if (disasm) {
+  const ArchSpec &arch = disasm->GetArchitecture();
   const lldb::ByteOrder byte_order = data.GetByteOrder();
 
   const uint32_t min_op_byte_size = arch.GetMinimumOpcodeByteSize();
@@ -232,7 +216,7 @@ public:
   if (!got_op) {
 bool is_alternate_isa = false;
 DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-GetDisasmToUse(is_alternate_isa);
+GetDisasmToUse(is_alternate_isa, disasm);
 
 const llvm::Triple::ArchType machine = arch.GetMachine();
 if (machine == llvm::Triple::arm || machine == llvm::Triple::thumb) {
@@ -261,10 +245,8 @@ public:
  

[Lldb-commits] [PATCH] D51319: Use a RAII guard to control access to DisassemblerLLVMC.

2018-08-28 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL340835: Use a RAII guard to control access to 
DisassemblerLLVMC. (authored by teemperor, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D51319?vs=162775&id=162879#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D51319

Files:
  lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
  lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h

Index: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h
===
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h
@@ -77,19 +77,6 @@
   uint64_t ReferencePC,
   const char **ReferenceName);
 
-  void Lock(InstructionLLVMC *inst,
-const lldb_private::ExecutionContext *exe_ctx) {
-m_mutex.lock();
-m_inst = inst;
-m_exe_ctx = exe_ctx;
-  }
-
-  void Unlock() {
-m_inst = NULL;
-m_exe_ctx = NULL;
-m_mutex.unlock();
-  }
-
   const lldb_private::ExecutionContext *m_exe_ctx;
   InstructionLLVMC *m_inst;
   std::mutex m_mutex;
Index: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
===
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
@@ -98,16 +98,15 @@
 
   bool DoesBranch() override {
 if (m_does_branch == eLazyBoolCalculate) {
-  std::shared_ptr disasm_sp(GetDisassembler());
-  if (disasm_sp) {
-disasm_sp->Lock(this, NULL);
+  DisassemblerScope disasm(*this);
+  if (disasm) {
 DataExtractor data;
 if (m_opcode.GetData(data)) {
   bool is_alternate_isa;
   lldb::addr_t pc = m_address.GetFileAddress();
 
   DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-  GetDisasmToUse(is_alternate_isa);
+  GetDisasmToUse(is_alternate_isa, disasm);
   const uint8_t *opcode_data = data.GetDataStart();
   const size_t opcode_data_len = data.GetByteSize();
   llvm::MCInst inst;
@@ -125,24 +124,22 @@
   m_does_branch = eLazyBoolNo;
   }
 }
-disasm_sp->Unlock();
   }
 }
 return m_does_branch == eLazyBoolYes;
   }
 
   bool HasDelaySlot() override {
 if (m_has_delay_slot == eLazyBoolCalculate) {
-  std::shared_ptr disasm_sp(GetDisassembler());
-  if (disasm_sp) {
-disasm_sp->Lock(this, NULL);
+  DisassemblerScope disasm(*this);
+  if (disasm) {
 DataExtractor data;
 if (m_opcode.GetData(data)) {
   bool is_alternate_isa;
   lldb::addr_t pc = m_address.GetFileAddress();
 
   DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-  GetDisasmToUse(is_alternate_isa);
+  GetDisasmToUse(is_alternate_isa, disasm);
   const uint8_t *opcode_data = data.GetDataStart();
   const size_t opcode_data_len = data.GetByteSize();
   llvm::MCInst inst;
@@ -160,38 +157,25 @@
   m_has_delay_slot = eLazyBoolNo;
   }
 }
-disasm_sp->Unlock();
   }
 }
 return m_has_delay_slot == eLazyBoolYes;
   }
 
   DisassemblerLLVMC::MCDisasmInstance *GetDisasmToUse(bool &is_alternate_isa) {
-is_alternate_isa = false;
-std::shared_ptr disasm_sp(GetDisassembler());
-if (disasm_sp) {
-  if (disasm_sp->m_alternate_disasm_up) {
-const AddressClass address_class = GetAddressClass();
-
-if (address_class == AddressClass::eCodeAlternateISA) {
-  is_alternate_isa = true;
-  return disasm_sp->m_alternate_disasm_up.get();
-}
-  }
-  return disasm_sp->m_disasm_up.get();
-}
-return nullptr;
+DisassemblerScope disasm(*this);
+return GetDisasmToUse(is_alternate_isa, disasm);
   }
 
   size_t Decode(const lldb_private::Disassembler &disassembler,
 const lldb_private::DataExtractor &data,
 lldb::offset_t data_offset) override {
 // All we have to do is read the opcode which can be easy for some
 // architectures
 bool got_op = false;
-std::shared_ptr disasm_sp(GetDisassembler());
-if (disasm_sp) {
-  const ArchSpec &arch = disasm_sp->GetArchitecture();
+DisassemblerScope disasm(*this);
+if (disasm) {
+  const ArchSpec &arch = disasm->GetArchitecture();
   const lldb::ByteOrder byte_order = data.GetByteOrder();
 
   const uint32_t min_op_byte_size = arch.GetMinimumOpcodeByteSize();
@@ -232,7 +216,7 @@
   if (!got_op) {
 bool is_alternate_isa = false;
 DisassemblerLLVMC::MCDisasmInstance *mc_disasm_ptr =
-GetDisasmToUse(is_a

[Lldb-commits] [PATCH] D51319: Use a RAII guard to control access to DisassemblerLLVMC.

2018-08-28 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added inline comments.



Comment at: source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:176
 bool got_op = false;
-std::shared_ptr disasm_sp(GetDisassembler());
-if (disasm_sp) {
-  const ArchSpec &arch = disasm_sp->GetArchitecture();
+DisassemblerScope disasm(*this);
+if (disasm) {

vsk wrote:
> Were all callers into Decode locking the disasm instance prior to this patch? 
> If not, this is a sweet fix.
Not from what I can see. Otherwise I would have seen deadlocks when adding this 
lock here.


Repository:
  rL LLVM

https://reviews.llvm.org/D51319



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r340841 - Respect platform sysroot when loading core files

2018-08-28 Thread Pavel Labath via lldb-commits
Author: labath
Date: Tue Aug 28 09:32:46 2018
New Revision: 340841

URL: http://llvm.org/viewvc/llvm-project?rev=340841&view=rev
Log:
Respect platform sysroot when loading core files

Patch by Eugene Birukov 
Differential Revision: https://reviews.llvm.org/D49685

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
lldb/trunk/source/Target/Platform.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py?rev=340841&r1=340840&r2=340841&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
 Tue Aug 28 09:32:46 2018
@@ -6,6 +6,7 @@ from __future__ import print_function
 
 import shutil
 import struct
+import os
 
 import lldb
 from lldbsuite.test.decorators import *
@@ -203,6 +204,30 @@ class LinuxCoreTestCase(TestBase):
 for regname, value in values.iteritems():
 self.expect("register read {}".format(regname), substrs=["{} = 
{}".format(regname, value)])
 
+@expectedFailureAll(bugnumber="llvm.org/pr37371", hostoslist=["windows"])
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+def test_i386_sysroot(self):
+"""Test that lldb can find the exe for an i386 linux core file using 
the sysroot."""
+
+# Copy linux-i386.out to tmp_sysroot/home/labath/test/a.out (since it 
was compiled as
+# /home/labath/test/a.out)
+tmp_sysroot = os.path.join(self.getBuildDir(), 
"lldb_i386_mock_sysroot")
+executable = os.path.join(tmp_sysroot, "home", "labath", "test", 
"a.out")
+lldbutil.mkdir_p(os.path.dirname(executable))
+shutil.copyfile("linux-i386.out", executable)
+
+# Set sysroot and load core
+self.runCmd("platform select remote-linux --sysroot '%s'" % 
tmp_sysroot)
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-i386.core")
+
+# Check that we found a.out from the sysroot
+self.check_all(process, self._i386_pid, self._i386_regions, "a.out")
+
+self.dbg.DeleteTarget(target)
+
 def check_memory_regions(self, process, region_count):
 region_list = process.GetMemoryRegions()
 self.assertEqual(region_list.GetSize(), region_count)
@@ -299,15 +324,7 @@ class LinuxCoreTestCase(TestBase):
 self.dbg.SetOutputFileHandle(None, False)
 self.dbg.SetErrorFileHandle(None, False)
 
-def do_test(self, filename, pid, region_count, thread_name):
-target = self.dbg.CreateTarget(filename + ".out")
-process = target.LoadCore(filename + ".core")
-self.assertTrue(process, PROCESS_IS_VALID)
-self.assertEqual(process.GetNumThreads(), 1)
-self.assertEqual(process.GetProcessID(), pid)
-
-self.check_state(process)
-
+def check_stack(self, process, pid, thread_name):
 thread = process.GetSelectedThread()
 self.assertTrue(thread)
 self.assertEqual(thread.GetThreadID(), pid)
@@ -324,6 +341,21 @@ class LinuxCoreTestCase(TestBase):
 frame.FindVariable("F").GetValueAsUnsigned(), ord(
 backtrace[i][0]))
 
+def check_all(self, process, pid, region_count, thread_name):
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertEqual(process.GetNumThreads(), 1)
+self.assertEqual(process.GetProcessID(), pid)
+
+self.check_state(process)
+
+self.check_stack(process, pid, thread_name)
+
 self.check_memory_regions(process, region_count)
 
+def do_test(self, filename, pid, region_count, thread_name):
+target = self.dbg.CreateTarget(filename + ".out")
+process = target.LoadCore(filename + ".core")
+
+self.check_all(process, pid, region_count, thread_name)
+
 self.dbg.DeleteTarget(target)

Modified: lldb/trunk/source/Target/Platform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Platform.cpp?rev=340841&r1=340840&r2=340841&view=diff
==
--- lldb/trunk/source/Target/Platform.cpp (original)
+++ lldb/trunk/source/Target/Platform.cpp Tue Aug 28 09:32:46 2018
@@ -228,16 +228,35 @@ Status Platform::GetSharedModule(const M
 module_spec, module_sp, module_search_paths_ptr, old_module_sp_ptr,
 did_create_ptr, false);
 
-  return GetRemoteSharedModule(module_spec, process, module_sp,
-   [&](const ModuleSpec &spec) {
- Status error = ModuleList::GetShar

Re: [Lldb-commits] [PATCH] D51208: [DWARF] Fix dwarf5-index-is-used.cpp

2018-08-28 Thread David Blaikie via lldb-commits
On Tue, Aug 28, 2018 at 7:33 AM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:

> clayborg added a comment.
>
> In https://reviews.llvm.org/D51208#1214743, @dblaikie wrote:
>
> > >> But if LLDB has different performance characteristics, or the default
> should be different for other reasons - I'm fine with that. I think I left
> it on for Apple so as not to mess with their stuff because of the
> MachO/dsym sort of thing that's a bit different from the environments I'm
> looking at.
> > >
> > > These are the numbers from my llvm-dev email in June:
> > >
> > >> setting a breakpoint on a non-existing function without the use of
> > >>  accelerator tables:
> > >>  real0m5.554s
> > >>  user0m43.764s
> > >>  sys 0m6.748s
> > >>
> > >> setting a breakpoint on a non-existing function with accelerator
> tables:
> > >>  real0m3.517s
> > >>  user0m3.136s
> > >>  sys 0m0.376s
> > >
> > > This is an extreme case,
> >
> > What was being tested here? Is it a realistic case (ie: not a
> pathalogical case with an absurd number of symbols, etc)? Using ELF?
> Fission or not?
> >
> > How's it compare to GDB performance, I wonder? Perhaps LLDB hasn't been
> optimized for the non-indexed case and could be - though that'd still
> potentially motivate turning on indexes by default for LLDB until someone
> has a motivation to do any non-indexed performance tuning/improvements.
>
>
> The performance is huge for large binaries. LLDB doesn't need to manually
> index all DWARF if the accelerator tables are there, it does if they are
> not. Many people complain about the time it takes to index the DWARF, so
> avoiding will be a huge improvement. We have some server binaries that
> statically link in libc, libstdc++ and many other binaries and they are
> currently 11GB, with over 10GB of that being DWARF. It makes debugging with
> GDB and LLDB unusable when manual indexing of all that DWARF is needed.


How long's the GDB startup/indexing time? (I take it this is without split
DWARF?) & LLDB? Because I've observed some pretty large binaries without
indexes & GDB startup times in the minute or so.


> They have .debug_types enabled where they can on these binaries, but LTO
> tends to be the culprit that can't take advantage of the .debug_types so
> the binaries are still huge.
>

Not sure I follow - LTO should allow for even more compact debug info than
debug_types (because LTO will merge the types before generating DWARF which
means more compact debug info because there's no need to make the
isolated/slicable chunks that debug_types requires), I think..


> GDB performance is hard to compare to due to the way they import types.
> They import all types in a compile unit at the same time and have 3 layers
> of resolution as they parse. Their indexes, if created by a linker, just
> say "foo" exists in this compile unit somewhere, not the exact DIE offset,
> so their indexes are useful, but they don't help LLDB out as much as the
> DWARF 5 versions do.
>

Oh, yeah, I'm not suggesting LLDB should use GDB's indexes - but that if
GDB can get reasonable performance without precomputed indexes then that
might be an indication that LLDB is leaving some performance improvements
on the table that might be worth investigating at some point.

>> because practically the only thing we are doing is building the symbol
> index, but it's nice for demonstrating the amount of work that lldb needs
> to do without it. In practice, the ratio will not be this huge most of the
> time, because we will usually find some matches, and then will have to do
> some extra work, which will add a constant overhead to both sides. However,
> this means that the no-accel case will take even longer. I am not sure how
> this compares to gdb numbers, but I think the difference here is
> significant.
> >>
> >> Also, I am pretty sure the Apple folks, who afaik are in the process of
> switching to debug_names, will want to have them on by default for their
> targets (ping @aprantl, @JDevlieghere). I think the cleanest way (and one
> that best reflects the reality) to achieve that would be to have `-glldb`
> imply `-gpubnames`. As for whether we should emit debug_names for DWARF 5
> by default (-gdwarf-5 => -gpubnames) is a more tricky question, and I don't
> have a clear opinion on that (however, @probinson might).
> >>
> >> (In either case, I agree that there are circumstances in which having
> debug_names is not beneficial, so having a flag to control them is a good
> idea).
> >
> > *nod* Happy if you want to (or I can) have clang set pubnames on by
> default when tuning for LLDB, while allowing -gno-pubnames to turn them
> off. (& maybe we should have another alias for that flag, since debug_names
> isn't "pubnames", but that's pretty low-priority)
>
> .debug_pubnames and .debug_pubtypes are not useful for LLDB or any
> debugger in general so please don't enable for LLDB.


Oh, sure - I didn't mean to suggest that, it's just the name of 

[Lldb-commits] [PATCH] D51374: [LLDB] Fix script to work with GNU sed

2018-08-28 Thread Shoaib Meenai via Phabricator via lldb-commits
smeenai created this revision.
smeenai added reviewers: beanz, davide, xiaobai.

GNU sed and BSD sed have a different command-line syntax for in-place
editing, and the current form of the script would only work with BSD
sed. The easiest way to get cross-platform behavior is to specify a
backup suffix and then just delete the backup file at the end. (BSD sed
is the default on macOS, but it's possible to acquire GNU coreutils and
have your `sed` be GNU sed even on macOS; I'm aware it's not officially
supported in any capacity, but it's easy enough to support here.)

An alternative would be using `perl -p -i -e` instead of `sed -i`, but I
figured it was best to make the minimal working change.


https://reviews.llvm.org/D51374

Files:
  scripts/framework-header-fix.sh


Index: scripts/framework-header-fix.sh
===
--- scripts/framework-header-fix.sh
+++ scripts/framework-header-fix.sh
@@ -2,12 +2,13 @@
 # Usage: framework-header-fix.sh  
 for file in `find $1 -name "*.h"`
 do
-  sed -i '' 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 /1' 
"$file"
-  sed -i '' 's|/1' "$file"
+  sed -i.bak 's|Index: scripts/framework-header-fix.sh
===
--- scripts/framework-header-fix.sh
+++ scripts/framework-header-fix.sh
@@ -2,12 +2,13 @@
 # Usage: framework-header-fix.sh  
 for file in `find $1 -name "*.h"`
 do
-  sed -i '' 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 /1' "$file"
-  sed -i '' 's|/1' "$file"
+  sed -i.bak 's|___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D50751: Allow use of self.filecheck in LLDB tests (c.f self.expect)

2018-08-28 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor requested changes to this revision.
teemperor added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/packages/Python/lldbsuite/test/configuration.py:194
+# of the test build dir is the LLVM build dir.
+llvm_build_dir = os.path.dirname(os.path.abspath(test_build_dir))
+assert os.path.lexists(llvm_build_dir)

This is true if we build LLDB as part of LLVM, but this doesn't seem correct if 
LLDB is built against an existing LLVM (which is in general supported in LLDB's 
CMake if IIUC). I think the best way is to pass the binary directory for this 
to dotest and configure it in the lit.cfg.



Comment at: lldb/packages/Python/lldbsuite/test/configuration.py:204
+filecheck_path = os.path.join(get_llvm_build_dir(), "bin", "FileCheck")
+assert os.path.lexists(filecheck_path)
+return filecheck_path

Windows itself can probably handle the fact that the `.exe` suffix is missing 
for FileCheck, but this assert will fail in this situation.



Comment at: lldb/packages/Python/lldbsuite/test/lldbtest.py:51
 import sys
+import commands
+import tempfile

I think that list is supposed to be sorted alphabetically



Comment at: lldb/packages/Python/lldbsuite/test/lldbtest.py:2166
+# Write the output to a temporary file.
+input_file = tempfile.NamedTemporaryFile()
+input_file.write(output)

Making a temporary file and opening it later by name is not really supported 
(see the NamedTemporaryFile docs). Could we maybe pass the output to FileCheck 
via stdin? That would also save us from the detour over the fs.



Comment at: lldb/packages/Python/lldbsuite/test/lldbtest.py:2181
+filecheck_bin = configuration.get_filecheck_path()
+filecheck_cmd = "{0} {1} -input-file {2} {3}".format(filecheck_bin,
+check_file_abs, input_file.name, filecheck_options)

We should quote the paths in here. Or at least, the temporary file path should 
be quoted as it will contain spaces on some setups.


https://reviews.llvm.org/D50751



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r340876 - [lldb] Fix lldb build on musl

2018-08-28 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Tue Aug 28 15:17:28 2018
New Revision: 340876

URL: http://llvm.org/viewvc/llvm-project?rev=340876&view=rev
Log:
[lldb] Fix lldb build on musl

Summary: limits.h is needed for getting PATH_MAX definition, this comes to fore
with musl libc where limits.h is not included indirectly via other system 
headers.

Patch by Khem Raj, thanks!

Reviewers: compnerd

Reviewed By: compnerd

Subscribers: llvm-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D31275

Modified:
lldb/trunk/source/Utility/FileSpec.cpp

Modified: lldb/trunk/source/Utility/FileSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/FileSpec.cpp?rev=340876&r1=340875&r2=340876&view=diff
==
--- lldb/trunk/source/Utility/FileSpec.cpp (original)
+++ lldb/trunk/source/Utility/FileSpec.cpp Tue Aug 28 15:17:28 2018
@@ -27,6 +27,7 @@
 #include// for vector
 
 #include  // for assert
+#include  // for PATH_MAX
 #include   // for size_t, NULL, snpr...
 #include  // for strcmp
 


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D31275: [lldb] Fix lldb build on musl

2018-08-28 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB340876: [lldb] Fix lldb build on musl (authored by 
teemperor, committed by ).
Herald added subscribers: lldb-commits, abidh.

Changed prior to commit:
  https://reviews.llvm.org/D31275?vs=143455&id=162969#toc

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D31275

Files:
  source/Utility/FileSpec.cpp


Index: source/Utility/FileSpec.cpp
===
--- source/Utility/FileSpec.cpp
+++ source/Utility/FileSpec.cpp
@@ -27,6 +27,7 @@
 #include// for vector
 
 #include  // for assert
+#include  // for PATH_MAX
 #include   // for size_t, NULL, snpr...
 #include  // for strcmp
 


Index: source/Utility/FileSpec.cpp
===
--- source/Utility/FileSpec.cpp
+++ source/Utility/FileSpec.cpp
@@ -27,6 +27,7 @@
 #include// for vector
 
 #include  // for assert
+#include  // for PATH_MAX
 #include   // for size_t, NULL, snpr...
 #include  // for strcmp
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D50751: Allow use of self.filecheck in LLDB tests (c.f self.expect)

2018-08-28 Thread Stella Stamenova via Phabricator via lldb-commits
stella.stamenova added inline comments.



Comment at: lldb/packages/Python/lldbsuite/test/configuration.py:194
+# of the test build dir is the LLVM build dir.
+llvm_build_dir = os.path.dirname(os.path.abspath(test_build_dir))
+assert os.path.lexists(llvm_build_dir)

teemperor wrote:
> This is true if we build LLDB as part of LLVM, but this doesn't seem correct 
> if LLDB is built against an existing LLVM (which is in general supported in 
> LLDB's CMake if IIUC). I think the best way is to pass the binary directory 
> for this to dotest and configure it in the lit.cfg.
Rather than making the change here, as @teemperor pointed out, you should use 
the existing mechanisms we have in the CMake files. Look for 
LLDB_DEFAULT_TEST_DSYMUTIL to see how we handle this (and the extension too!) 
for dsymutil.




https://reviews.llvm.org/D50751



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r340877 - Remove unnecessary entitlement in debugserver for iOS.

2018-08-28 Thread Jason Molenda via lldb-commits
Author: jmolenda
Date: Tue Aug 28 15:28:34 2018
New Revision: 340877

URL: http://llvm.org/viewvc/llvm-project?rev=340877&view=rev
Log:
Remove unnecessary entitlement in debugserver for iOS.
 

Modified:
lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist

Modified: lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist?rev=340877&r1=340876&r2=340877&view=diff
==
--- lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist 
(original)
+++ lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist Tue Aug 
28 15:28:34 2018
@@ -12,8 +12,6 @@
 
 com.apple.frontboard.debugapplications
 
-run-unsigned-code
-
 seatbelt-profiles
 
 debugserver


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51387: Allow Template argument accessors to automatically unwrap parameter packs

2018-08-28 Thread Frederic Riss via Phabricator via lldb-commits
friss created this revision.
friss added reviewers: jingham, clayborg.
Herald added a subscriber: JDevlieghere.

When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.

This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.

A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.

The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.


https://reviews.llvm.org/D51387

Files:
  include/lldb/Symbol/ClangASTContext.h
  include/lldb/Symbol/CompilerType.h
  include/lldb/Symbol/GoASTContext.h
  include/lldb/Symbol/JavaASTContext.h
  include/lldb/Symbol/OCamlASTContext.h
  include/lldb/Symbol/TypeSystem.h
  
packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/TestTemplatePackArgs.py
  packages/Python/lldbsuite/test/lang/cpp/class-template-parameter-pack/main.cpp
  source/API/SBType.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  source/Symbol/ClangASTContext.cpp
  source/Symbol/CompilerType.cpp
  source/Symbol/JavaASTContext.cpp
  source/Symbol/TypeSystem.cpp

Index: source/Symbol/TypeSystem.cpp
===
--- source/Symbol/TypeSystem.cpp
+++ source/Symbol/TypeSystem.cpp
@@ -102,18 +102,19 @@
 }
 
 TemplateArgumentKind
-TypeSystem::GetTemplateArgumentKind(opaque_compiler_type_t type, size_t idx) {
+TypeSystem::GetTemplateArgumentKind(opaque_compiler_type_t type, size_t idx,
+bool expand_pack) {
   return eTemplateArgumentKindNull;
 }
 
 CompilerType TypeSystem::GetTypeTemplateArgument(opaque_compiler_type_t type,
- size_t idx) {
+ size_t idx, bool expand_pack) {
   return CompilerType();
 }
 
 llvm::Optional
-TypeSystem::GetIntegralTemplateArgument(opaque_compiler_type_t type,
-size_t idx) {
+TypeSystem::GetIntegralTemplateArgument(opaque_compiler_type_t type, size_t idx,
+bool expand_pack) {
   return llvm::None;
 }
 
Index: source/Symbol/JavaASTContext.cpp
===
--- source/Symbol/JavaASTContext.cpp
+++ source/Symbol/JavaASTContext.cpp
@@ -879,7 +879,8 @@
 }
 
 size_t
-JavaASTContext::GetNumTemplateArguments(lldb::opaque_compiler_type_t type) {
+JavaASTContext::GetNumTemplateArguments(lldb::opaque_compiler_type_t type,
+bool expand_pack) {
   return 0;
 }
 
Index: source/Symbol/CompilerType.cpp
===
--- source/Symbol/CompilerType.cpp
+++ source/Symbol/CompilerType.cpp
@@ -680,30 +680,32 @@
   return 0;
 }
 
-size_t CompilerType::GetNumTemplateArguments() const {
+size_t CompilerType::GetNumTemplateArguments(bool expand_pack) const {
   if (IsValid()) {
-return m_type_system->GetNumTemplateArguments(m_type);
+return m_type_system->GetNumTemplateArguments(m_type, expand_pack);
   }
   return 0;
 }
 
-TemplateArgumentKind CompilerType::GetTemplateArgumentKind(size_t idx) const {
+TemplateArgumentKind
+CompilerType::GetTemplateArgumentKind(size_t idx, bool expand_pack) const {
   if (IsValid())
-return m_type_system->GetTemplateArgumentKind(m_type, idx);
+return m_type_system->GetTemplateArgumentKind(m_type, idx, expand_pack);
   return eTemplateArgumentKindNull;
 }
 
-CompilerType CompilerType::GetTypeTemplateArgument(size_t idx) const {
+CompilerType CompilerType::GetTypeTemplateArgument(size_t idx,
+   bool expand_pack) const {
   if (IsValid()) {
-return m_type_system->GetTypeTemplateArgument(m_type, idx);
+return m_type_system->GetTypeTemplateArgument(m_type, idx, expand_pack);
   }
   return CompilerType();
 }
 
 llvm::Optional
-CompilerType::GetIntegralTemplateArgument(size_t idx) const {
+CompilerType::GetIntegralTemplateArgument(size_t idx, bool expand_pack) const {
   if (IsValid())
-return m_type_system->GetIntegralTemplateArgument(m_type, idx);
+return m_type_system->GetIntegralTemplateArgument(m_type, idx, expand_pack);
   return llvm::None;
 }
 
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -7546,7 +7546,8 @@
 }
 
 size_t
-ClangASTContext::GetNumTemplateArguments(lldb::opaque_compiler_type_t type) {
+ClangASTContext:

[Lldb-commits] [lldb] r340880 - Allow IRInterpreter to deal with non-power-of-2 sized types to support some bitfield accesses.

2018-08-28 Thread Frederic Riss via lldb-commits
Author: friss
Date: Tue Aug 28 15:50:01 2018
New Revision: 340880

URL: http://llvm.org/viewvc/llvm-project?rev=340880&view=rev
Log:
Allow IRInterpreter to deal with non-power-of-2 sized types to support some 
bitfield accesses.

Summary:
For some bitfield patterns (like the one added by this commit), Clang will
generate non-regular data types like i24 or i48. This patch follows a
pretty naive approach of just bumping the type size to the next power of 2.
DataExtractor know how to deal with weird sizes. The operations on Scalar
do not know how to deal with those types though, so we have to legalize the
size when creating a Scalar.

Reviewers: jingham, clayborg

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D51245

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
lldb/trunk/source/Expression/IRInterpreter.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py?rev=340880&r1=340879&r2=340880&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py 
Tue Aug 28 15:50:01 2018
@@ -116,6 +116,38 @@ class BitfieldsTestCase(TestBase):
 self.expect("expr/x (packed.c)", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=['uint32_t', "7112233"])
 
+for bit in range(1,18):
+expected = "1" if bit in [1, 5, 7, 13] else "0"
+self.expect("expr even_more_bits.b" + str(bit), 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', expected])
+
+for bit in [3, 10, 14]:
+self.expect("expr even_more_bits.b" + str(bit) + " = 1", 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', "1"])
+
+self.expect(
+"frame variable --show-types even_more_bits",
+VARIABLES_DISPLAYED_CORRECTLY,
+substrs=[
+'(uint8_t:1) b1 = \'\\x01\'',
+'(uint8_t:1) b2 = \'\\0\'',
+'(uint8_t:1) b3 = \'\\x01\'',
+'(uint8_t:1) b4 = \'\\0\'',
+'(uint8_t:1) b5 = \'\\x01\'',
+'(uint8_t:1) b6 = \'\\0\'',
+'(uint8_t:1) b7 = \'\\x01\'',
+'(uint8_t:1) b8 = \'\\0\'',
+'(uint8_t:1) b9 = \'\\0\'',
+'(uint8_t:1) b10 = \'\\x01\'',
+'(uint8_t:1) b12 = \'\\0\'',
+'(uint8_t:1) b13 = \'\\x01\'',
+'(uint8_t:1) b14 = \'\\x01\'',
+'(uint8_t:1) b15 = \'\\0\'',
+'(uint8_t:1) b16 = \'\\0\'',
+'(uint8_t:1) b17 = \'\\0\'',
+])
+
+
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
 # (http://llvm.org/pr21800)

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c?rev=340880&r1=340879&r2=340880&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c Tue Aug 
28 15:50:01 2018
@@ -8,6 +8,7 @@
 
//===--===//
 #include 
 #include 
+#include 
 
 int main (int argc, char const *argv[])
 {
@@ -63,6 +64,20 @@ int main (int argc, char const *argv[])
 more_bits.c = 1;
 more_bits.d = 0;
 
+struct EvenMoreBits
+{
+uint8_t b1  : 1, b2  : 1, b3  : 1, b4  : 1, b5  : 1, b6  : 1,
+b7  : 1, b8  : 1, b9  : 1, b10 : 1, b11 : 1, b12 : 1,
+b13 : 1, b14 : 1, b15 : 1, b16 : 1, b17 : 1;
+};
+
+struct EvenMoreBits even_more_bits;
+memset(&even_more_bits, 0, sizeof(even_more_bits));
+even_more_bits.b1 = 1;
+even_more_bits.b5 = 1;
+even_more_bits.b7 = 1;
+even_more_bits.b13 = 1;
+
 #pragma pack(1)
 struct PackedBits
 {

Modified: lldb/trunk/source/Expression/IRInterpreter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRInterpreter.cpp?rev=340880&r1=340879&r2=340880&view=diff
==
--- lldb/trunk/source/Expression/IRInterpreter.cpp (original)
+++ lldb/trunk/source/Expression/IRInterpreter.cpp Tue Aug 28 15:50:01 2018
@@ -152,17 +152,13 @@ public:
  Type *type) {
 size_t type_size = m_target_data.getTypeStoreSize(type);
 
-switch (type_size) {
-case 1:
-cas

[Lldb-commits] [PATCH] D51245: Allow IRInterpreter to deal with non-power-of-2 sized types to support some bitfield accesses.

2018-08-28 Thread Frederic Riss via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB340880: Allow IRInterpreter to deal with non-power-of-2 
sized types to support some… (authored by friss, committed by ).
Herald added a subscriber: abidh.

Changed prior to commit:
  https://reviews.llvm.org/D51245?vs=162524&id=162976#toc

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51245

Files:
  packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
  packages/Python/lldbsuite/test/lang/c/bitfields/main.c
  source/Expression/IRInterpreter.cpp

Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -152,17 +152,13 @@
  Type *type) {
 size_t type_size = m_target_data.getTypeStoreSize(type);
 
-switch (type_size) {
-case 1:
-case 2:
-case 4:
-case 8:
-  scalar = llvm::APInt(type_size*8, u64value);
-  break;
-default:
+if (type_size > 8)
   return false;
-}
 
+if (type_size != 1)
+  type_size = PowerOf2Ceil(type_size);
+
+scalar = llvm::APInt(type_size*8, u64value);
 return true;
   }
 
@@ -192,8 +188,7 @@
 return false;
 
   lldb::offset_t offset = 0;
-  if (value_size == 1 || value_size == 2 || value_size == 4 ||
-  value_size == 8) {
+  if (value_size <= 8) {
 uint64_t u64value = value_extractor.GetMaxU64(&offset, value_size);
 return AssignToMatchType(scalar, u64value, value->getType());
   }
Index: packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
===
--- packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
+++ packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
@@ -116,6 +116,38 @@
 self.expect("expr/x (packed.c)", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=['uint32_t', "7112233"])
 
+for bit in range(1,18):
+expected = "1" if bit in [1, 5, 7, 13] else "0"
+self.expect("expr even_more_bits.b" + str(bit), VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', expected])
+
+for bit in [3, 10, 14]:
+self.expect("expr even_more_bits.b" + str(bit) + " = 1", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', "1"])
+
+self.expect(
+"frame variable --show-types even_more_bits",
+VARIABLES_DISPLAYED_CORRECTLY,
+substrs=[
+'(uint8_t:1) b1 = \'\\x01\'',
+'(uint8_t:1) b2 = \'\\0\'',
+'(uint8_t:1) b3 = \'\\x01\'',
+'(uint8_t:1) b4 = \'\\0\'',
+'(uint8_t:1) b5 = \'\\x01\'',
+'(uint8_t:1) b6 = \'\\0\'',
+'(uint8_t:1) b7 = \'\\x01\'',
+'(uint8_t:1) b8 = \'\\0\'',
+'(uint8_t:1) b9 = \'\\0\'',
+'(uint8_t:1) b10 = \'\\x01\'',
+'(uint8_t:1) b12 = \'\\0\'',
+'(uint8_t:1) b13 = \'\\x01\'',
+'(uint8_t:1) b14 = \'\\x01\'',
+'(uint8_t:1) b15 = \'\\0\'',
+'(uint8_t:1) b16 = \'\\0\'',
+'(uint8_t:1) b17 = \'\\0\'',
+])
+
+
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
 # (http://llvm.org/pr21800)
Index: packages/Python/lldbsuite/test/lang/c/bitfields/main.c
===
--- packages/Python/lldbsuite/test/lang/c/bitfields/main.c
+++ packages/Python/lldbsuite/test/lang/c/bitfields/main.c
@@ -8,6 +8,7 @@
 //===--===//
 #include 
 #include 
+#include 
 
 int main (int argc, char const *argv[])
 {
@@ -63,6 +64,20 @@
 more_bits.c = 1;
 more_bits.d = 0;
 
+struct EvenMoreBits
+{
+uint8_t b1  : 1, b2  : 1, b3  : 1, b4  : 1, b5  : 1, b6  : 1,
+b7  : 1, b8  : 1, b9  : 1, b10 : 1, b11 : 1, b12 : 1,
+b13 : 1, b14 : 1, b15 : 1, b16 : 1, b17 : 1;
+};
+
+struct EvenMoreBits even_more_bits;
+memset(&even_more_bits, 0, sizeof(even_more_bits));
+even_more_bits.b1 = 1;
+even_more_bits.b5 = 1;
+even_more_bits.b7 = 1;
+even_more_bits.b13 = 1;
+
 #pragma pack(1)
 struct PackedBits
 {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51245: Allow IRInterpreter to deal with non-power-of-2 sized types to support some bitfield accesses.

2018-08-28 Thread Frederic Riss via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL340880: Allow IRInterpreter to deal with non-power-of-2 
sized types to support some… (authored by friss, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D51245

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
  lldb/trunk/source/Expression/IRInterpreter.cpp

Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
@@ -116,6 +116,38 @@
 self.expect("expr/x (packed.c)", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=['uint32_t', "7112233"])
 
+for bit in range(1,18):
+expected = "1" if bit in [1, 5, 7, 13] else "0"
+self.expect("expr even_more_bits.b" + str(bit), VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', expected])
+
+for bit in [3, 10, 14]:
+self.expect("expr even_more_bits.b" + str(bit) + " = 1", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint8_t', "1"])
+
+self.expect(
+"frame variable --show-types even_more_bits",
+VARIABLES_DISPLAYED_CORRECTLY,
+substrs=[
+'(uint8_t:1) b1 = \'\\x01\'',
+'(uint8_t:1) b2 = \'\\0\'',
+'(uint8_t:1) b3 = \'\\x01\'',
+'(uint8_t:1) b4 = \'\\0\'',
+'(uint8_t:1) b5 = \'\\x01\'',
+'(uint8_t:1) b6 = \'\\0\'',
+'(uint8_t:1) b7 = \'\\x01\'',
+'(uint8_t:1) b8 = \'\\0\'',
+'(uint8_t:1) b9 = \'\\0\'',
+'(uint8_t:1) b10 = \'\\x01\'',
+'(uint8_t:1) b12 = \'\\0\'',
+'(uint8_t:1) b13 = \'\\x01\'',
+'(uint8_t:1) b14 = \'\\x01\'',
+'(uint8_t:1) b15 = \'\\0\'',
+'(uint8_t:1) b16 = \'\\0\'',
+'(uint8_t:1) b17 = \'\\0\'',
+])
+
+
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
 # (http://llvm.org/pr21800)
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
@@ -8,6 +8,7 @@
 //===--===//
 #include 
 #include 
+#include 
 
 int main (int argc, char const *argv[])
 {
@@ -63,6 +64,20 @@
 more_bits.c = 1;
 more_bits.d = 0;
 
+struct EvenMoreBits
+{
+uint8_t b1  : 1, b2  : 1, b3  : 1, b4  : 1, b5  : 1, b6  : 1,
+b7  : 1, b8  : 1, b9  : 1, b10 : 1, b11 : 1, b12 : 1,
+b13 : 1, b14 : 1, b15 : 1, b16 : 1, b17 : 1;
+};
+
+struct EvenMoreBits even_more_bits;
+memset(&even_more_bits, 0, sizeof(even_more_bits));
+even_more_bits.b1 = 1;
+even_more_bits.b5 = 1;
+even_more_bits.b7 = 1;
+even_more_bits.b13 = 1;
+
 #pragma pack(1)
 struct PackedBits
 {
Index: lldb/trunk/source/Expression/IRInterpreter.cpp
===
--- lldb/trunk/source/Expression/IRInterpreter.cpp
+++ lldb/trunk/source/Expression/IRInterpreter.cpp
@@ -152,17 +152,13 @@
  Type *type) {
 size_t type_size = m_target_data.getTypeStoreSize(type);
 
-switch (type_size) {
-case 1:
-case 2:
-case 4:
-case 8:
-  scalar = llvm::APInt(type_size*8, u64value);
-  break;
-default:
+if (type_size > 8)
   return false;
-}
 
+if (type_size != 1)
+  type_size = PowerOf2Ceil(type_size);
+
+scalar = llvm::APInt(type_size*8, u64value);
 return true;
   }
 
@@ -192,8 +188,7 @@
 return false;
 
   lldb::offset_t offset = 0;
-  if (value_size == 1 || value_size == 2 || value_size == 4 ||
-  value_size == 8) {
+  if (value_size <= 8) {
 uint64_t u64value = value_extractor.GetMaxU64(&offset, value_size);
 return AssignToMatchType(scalar, u64value, value->getType());
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51374: [LLDB] Fix script to work with GNU sed

2018-08-28 Thread Alex Langford via Phabricator via lldb-commits
xiaobai accepted this revision.
xiaobai added a comment.

Regardless of compatibility, the man page for sed on OSX recommends not having 
a zero length extension while editing the file in place. LGTM.


https://reviews.llvm.org/D51374



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51374: [LLDB] Fix script to work with GNU sed

2018-08-28 Thread Shoaib Meenai via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB340885: [LLDB] Fix script to work with GNU sed (authored 
by smeenai, committed by ).
Herald added a subscriber: abidh.

Changed prior to commit:
  https://reviews.llvm.org/D51374?vs=162928&id=162988#toc

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51374

Files:
  scripts/framework-header-fix.sh


Index: scripts/framework-header-fix.sh
===
--- scripts/framework-header-fix.sh
+++ scripts/framework-header-fix.sh
@@ -2,12 +2,13 @@
 # Usage: framework-header-fix.sh  
 for file in `find $1 -name "*.h"`
 do
-  sed -i '' 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 /1' 
"$file"
-  sed -i '' 's|/1' "$file"
+  sed -i.bak 's|Index: scripts/framework-header-fix.sh
===
--- scripts/framework-header-fix.sh
+++ scripts/framework-header-fix.sh
@@ -2,12 +2,13 @@
 # Usage: framework-header-fix.sh  
 for file in `find $1 -name "*.h"`
 do
-  sed -i '' 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 /1' "$file"
-  sed -i '' 's|/1' "$file"
+  sed -i.bak 's|___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r340885 - [LLDB] Fix script to work with GNU sed

2018-08-28 Thread Shoaib Meenai via lldb-commits
Author: smeenai
Date: Tue Aug 28 16:47:22 2018
New Revision: 340885

URL: http://llvm.org/viewvc/llvm-project?rev=340885&view=rev
Log:
[LLDB] Fix script to work with GNU sed

GNU sed and BSD sed have a different command-line syntax for in-place
editing, and the current form of the script would only work with BSD
sed. The easiest way to get cross-platform behavior is to specify a
backup suffix and then just delete the backup file at the end. (BSD sed
is the default on macOS, but it's possible to acquire GNU coreutils and
have your `sed` be GNU sed even on macOS; I'm aware it's not officially
supported in any capacity, but it's easy enough to support here.)

An alternative would be using `perl -p -i -e` instead of `sed -i`, but I
figured it was best to make the minimal working change.

Differential Revision: https://reviews.llvm.org/D51374

Modified:
lldb/trunk/scripts/framework-header-fix.sh

Modified: lldb/trunk/scripts/framework-header-fix.sh
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/framework-header-fix.sh?rev=340885&r1=340884&r2=340885&view=diff
==
--- lldb/trunk/scripts/framework-header-fix.sh (original)
+++ lldb/trunk/scripts/framework-header-fix.sh Tue Aug 28 16:47:22 2018
@@ -2,12 +2,13 @@
 # Usage: framework-header-fix.sh  
 for file in `find $1 -name "*.h"`
 do
-  sed -i '' 's/\(#include\)[ ]*"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 /1' 
"$file"
-  sed -i '' 's|/1' "$file"
+  sed -i.bak 's|http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51374: [LLDB] Fix script to work with GNU sed

2018-08-28 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

LGTM


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51374



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D51104: [PDB] Resolve a symbol context block info correctly

2018-08-28 Thread Aaron Smith via Phabricator via lldb-commits
asmith accepted this revision.
asmith added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51104



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits