[Lldb-commits] [PATCH] D40467: DWZ 04/12: Separate Offset also into FileOffset

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

> Please undo all renaming from offset to file_offset.

I am preparing now a split of this patch for the renaming part + the "real" 
part, sorry I did not realize it is mostly about the renaming which is not 
worth your detailed review.

There are two different types of offsets:

| `UniqOffset` | One DIE from a `DW_TAG_partial_unit` gets two different 
`UniqOffset` depending from which `DW_TAG_compile_unit` it was included |
| `FileOffset` | One DIE from a `DW_TAG_partial_unit` has only one `FileOffset` 
- where one can read it from `get_debug_info_data()` |

Most of LLDB works with `UniqOffset` so I kept the original `dw_offset_t 
offset` type+name for it. When LLDB works with `FileOffset` I call it 
`dw_offset_t file_offset`. I really discourage calling these two different 
offset types the same as it is a bug (although affecting only DWZ files) if 
there is missing a proper conversion function between these two types.

I found overengineered to make a separate type-safe against accidental exchange 
wrapper class  for the `FileOffset' but I can if you prefer that over a simple 
renaming of all the variables/parameters.

https://reviews.llvm.org/D40474 introduces `DWARFFileOffset` which makes it 
type-safe against accidental exchange with `dw_offset_t` but that type includes 
also `bool is_dwz` whether it is in DWZ Common File or in the main symbol file 
which makes it excessive for the places where currently I used `dw_offset_t 
file_offset` because the file itself is known there.

> The "offset" you get from a  DIE should always be the absolute .debug_info 
> offset. No need to say file_offset.

We never talk about CU-relative offset.  I made remapping in 
`DWARFDebugInfoEntry`:

| `dw_offset_t GetOffset()` renamed to | `FileOffset`-kind `dw_offset_t 
GetFileOffset()`   |
| new  | `UniqOffset`-kind `dw_offset_t 
GetOffset(const DWARFCompileUnit *cu)` |




Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:207-226
+  dw_offset_t GetFileOffset() const { return m_data->m_file_offset; }
+  dw_offset_t FileOffsetToUniqOffset(dw_offset_t file) const {
+return ThisCUFileOffsetToUniq(file);
+  }
+  static dw_offset_t ThisCUFileOffsetToUniq_nocheck(dw_offset_t file) {
+return file;
+  }

clayborg wrote:
> Not a fan of these names. Can't these just be something like:
> 
> ```
> dw_offset_t GeCUtRelativeOffset(); // CU relative offset
> dw_offset_t GetOffset(); // Always absolute .debug_info offset
> ```
> 
> ThisCUUniqToFileOffset seems a bit unclear.
What should be `dw_offset_t GeCUtRelativeOffset(); // CU relative offset`?
This patchset never deals with offsets relative to the CU start (and LLDB never 
uses such offsets, `DWARFCompileUnit::ExtractDIEsIfNeeded` stores their 
`.debug_info`-relative offsets and `DWARFFormValue::Reference()` also converts 
everything into `.debug_info`-relative offsets.
| `UniqOffset` -> `FileOffset` | 
`DWARFDebugInfo::GetCompileUnit`{,`ContainingDIEOffset`} | slow 
`m_compile_units` bisecting |
| `UniqOffset` -> `FileOffset` | `DWARFCompileUnit::ThisCUUniqToFileOffset` | 
fast but the CU must match |
| `FileOffset` -> `UniqOffset` | `DWARFCompileUnit::ThisCUFileOffsetToUniq` | 
fast, this functionality requires to use matching CU |
`UniqOffset` is in the most simple case without using DWZ the same as 
`FileOffset`.  If DWZ is used then see the mapping in Summary above.
The methods cannot be called `Get' as they convert their parameter value, they 
are not getters.



https://reviews.llvm.org/D40467



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

[Lldb-commits] [PATCH] D40615: Fix assertion in ClangASTContext

[Pavel Labath via Phabricator via lldb-commits]

labath marked an inline comment as done.
labath added inline comments.



Comment at: include/lldb/Symbol/CompilerType.h:294
 
+  struct IntegralTemplateArgument;
+

clayborg wrote:
> Can't you just define the type right here?
Unfortunately, I can't because it contains a CompilerType member, which means 
CompilerType has to be a complete type, and this only happens after we reach 
the end of the class definition.

However, I may have gone a bit overboard with the nesting of this type inside 
CompilerType. I could make this just a standalone class if you think that will 
make things more understandable (a forward declaration will still be needed 
though).


https://reviews.llvm.org/D40615



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

[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

> you will probably be the only person who will be able to run these tests and 
> verify dwz functionality.

OK; really nobody runs RHEL/CentOS/Fedora? :-)

> If you don't setup a buildbot testing

OK, I will try that.  I was even running a test bot for GDB.

> These can range from checking in a couple of siple dwz files

OK; although during development various bugs required various testfiles, single 
testfiles does not catch it all but sure better than nothing.

> reimplementing/upstreaming the utilities necessary to build dwz files 
> ourselves (I am not sure what the dwz tool does, but the eu-strip and 
> sepdebugcrcfix tools sound like they would be fairly easy to implement on top 
> of existing llvm libraries).

DWZ has its upstream sources .
`eu-strip` is just a more optimized (and more ELF-details preserving) variant 
of GNU binutils `strip`. It should be easy to slightly extend `llvm-objcopy` 
(as there is no `llvm-strip`). Or is it OK to use GNU binutils `strip` instead?
`sepdebugcrcfix` is a small utility currently inside upstream `rpm` package so 
that could be reimplemented in LLVM.
Although I admit both `eu-strip` and `sepdebugcrcfix` are used in the LLDB 
testsuite only to workaround some DWZ bug it fails for some reason to process 
unsplit debug info. I did not find DWZ code convenient enough to bugfix it 
there and its author Jakub Jelínek does not fix its reported bugs in recent 
years.

> The other thing that worries me is that your comments seem to indicate that 
> not all dwz tests pass after this. Could you elaborate on the "Many ERRORs 
> are correct" part and how you plan to rectify that?

There is never any Success->Failure case for _dwarf->_dwz (there were such 
cases when I had bugs in my LLDB DWZ code).  But there are Success->Error cases 
because in some cases DWZ tool cannot be used such as:

  os command: make MAKE_DSYM=NO DWZ=YES ARCH=x86_64 
CC="/quad/home/jkratoch/redhat/llvm-git-build-release/bin/clang-6.0"
  with pid: 14709
  stdout:
  stderr: dwz: a.out.debug.dwz: .debug_info section not present
  make[4]: *** [../../make/Makefile.rules:538: a.out] Error 1
  retcode: 2
  ERROR
  Error when building test subject.

Unaware what to do with it. It could run the testcase without DWZ but then the 
_dwarf testcase would be needlessly run twice. Or there could be a list of 
tests to skip in DWZ mode. Or maybe some list of "ExpectedError" testcases (I 
guess one cannot defined "ExpectedError" now). This also means `make 
check-lldb` prints with DWZ a lot of error messages due to these "expected 
Errors".

> your comments seem to indicate that not all regular dwarf tests were passing 
> for you to begin with. Is that true?

Yes, I haven't investigated why yet.  I am used from GDB to only diff results 
against regressions.  RESULT-clean/ 
 or RESULT-clean.tar.xz 

BTW with installed system debug info files (`/usr/lib/debug/**.debug`) the LLDB 
testsuite times out and fails completely.  LLDB could have some option like: 
`gdb -iex 'set debug-file-directory /notexists'`

> Would you be willing to help me (probably in a separate thread) to identify 
> the tests that are failing and why?

Yes but I would like to put more attention at the DWZ support upstreaming first 
as it is a LLDB blocker for Fedora/RHEL/CentOS.


https://reviews.llvm.org/D40475



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

[Lldb-commits] [lldb] r319414 - Fix assertion in ClangASTContext

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu Nov 30 02:16:54 2017
New Revision: 319414

URL: http://llvm.org/viewvc/llvm-project?rev=319414&view=rev
Log:
Fix assertion in ClangASTContext

Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.

Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.

Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.

Reviewers: clayborg

Subscribers: lldb-commits

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

Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/include/lldb/Symbol/CompilerType.h
lldb/trunk/include/lldb/Symbol/TypeSystem.h
lldb/trunk/source/API/SBType.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxBitset.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Symbol/CompilerType.cpp
lldb/trunk/source/Symbol/TypeSystem.cpp
lldb/trunk/unittests/Symbol/TestClangASTContext.cpp

Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=319414&r1=319413&r2=319414&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Thu Nov 30 02:16:54 2017
@@ -787,7 +787,7 @@ public:
   size_t idx) override;
   CompilerType GetTypeTemplateArgument(lldb::opaque_compiler_type_t type,
size_t idx) override;
-  std::pair
+  llvm::Optional
   GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type,
   size_t idx) override;
 

Modified: lldb/trunk/include/lldb/Symbol/CompilerType.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/CompilerType.h?rev=319414&r1=319413&r2=319414&view=diff
==
--- lldb/trunk/include/lldb/Symbol/CompilerType.h (original)
+++ lldb/trunk/include/lldb/Symbol/CompilerType.h Thu Nov 30 02:16:54 2017
@@ -20,6 +20,7 @@
 // Project includes
 #include "lldb/Core/ClangForward.h"
 #include "lldb/lldb-private.h"
+#include "llvm/ADT/APSInt.h"
 
 namespace lldb_private {
 
@@ -290,6 +291,8 @@ public:
   // Exploring the type
   //--
 
+  struct IntegralTemplateArgument;
+
   uint64_t GetByteSize(ExecutionContextScope *exe_scope) const;
 
   uint64_t GetBitSize(ExecutionContextScope *exe_scope) const;
@@ -368,9 +371,9 @@ public:
   lldb::TemplateArgumentKind GetTemplateArgumentKind(size_t idx) const;
   CompilerType GetTypeTemplateArgument(size_t idx) const;
 
-  // Returns the value of the template argument and its type. In case the
-  // argument is not found, returns an invalid CompilerType.
-  std::pair GetIntegralTemplateArgument(size_t 
idx) const;
+  // Returns the value of the template argument and its type.
+  llvm::Optional
+  GetIntegralTemplateArgument(size_t idx) const;
 
   CompilerType GetTypeForFormatters() const;
 
@@ -433,6 +436,11 @@ private:
 bool operator==(const CompilerType &lhs, const CompilerType &rhs);
 bool operator!=(const CompilerType &lhs, const CompilerType &rhs);
 
+struct CompilerType::IntegralTemplateArgument {
+  llvm::APSInt value;
+  CompilerType type;
+};
+
 } // namespace lldb_private
 
 #endif // liblldb_CompilerType_h_

Modified: lldb/trunk/include/lldb/Symbol/TypeSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/TypeSystem.h?rev=319414&r1=319413&r2=319414&view=diff
==
--- lldb/trunk/include/lldb/Symbol/TypeSystem.h (original)
+++ lldb/trunk/include/lldb/Symbol/TypeSystem.h Thu Nov 30 02:16:54 2017
@@ -355,9 +355,8 @@ public:
   GetTemplateArgumentKind(lldb::opaque_compiler_type_t type, size_t idx);
   virtual CompilerType GetTypeTemplateArgument(lldb::opaque_compiler_type_t 
type,
size_t idx);
-  virtual std::pair
-  GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type,
-  size_t idx);
+  virtual llvm::Optional
+  GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type, size_t idx);
 
   //--
   // Dumping types

Modified: lldb/trunk/source/API/SBType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBType.cpp?rev=319414&r1=319413&r2=319414&view=diff
==
--- lldb/trunk/source/API/SBType.cpp (original)
+++ lldb/trunk/source/API/SBT

[Lldb-commits] [PATCH] D40615: Fix assertion in ClangASTContext

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL319414: Fix assertion in ClangASTContext (authored by 
labath).

Changed prior to commit:
  https://reviews.llvm.org/D40615?vs=124781&id=124890#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D40615

Files:
  lldb/trunk/include/lldb/Symbol/ClangASTContext.h
  lldb/trunk/include/lldb/Symbol/CompilerType.h
  lldb/trunk/include/lldb/Symbol/TypeSystem.h
  lldb/trunk/source/API/SBType.cpp
  lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxBitset.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp
  lldb/trunk/source/Symbol/CompilerType.cpp
  lldb/trunk/source/Symbol/TypeSystem.cpp
  lldb/trunk/unittests/Symbol/TestClangASTContext.cpp

Index: lldb/trunk/unittests/Symbol/TestClangASTContext.cpp
===
--- lldb/trunk/unittests/Symbol/TestClangASTContext.cpp
+++ lldb/trunk/unittests/Symbol/TestClangASTContext.cpp
@@ -382,8 +382,8 @@
   infos.names.push_back("T");
   infos.args.push_back(TemplateArgument(m_ast->getASTContext()->IntTy));
   infos.names.push_back("I");
-  infos.args.push_back(TemplateArgument(*m_ast->getASTContext(),
-llvm::APSInt(47),
+  llvm::APSInt arg(llvm::APInt(8, 47));
+  infos.args.push_back(TemplateArgument(*m_ast->getASTContext(), arg,
 m_ast->getASTContext()->IntTy));
 
   // template struct foo;
@@ -419,15 +419,16 @@
   eTemplateArgumentKindType);
 EXPECT_EQ(m_ast->GetTypeTemplateArgument(t.GetOpaqueQualType(), 0),
   int_type);
-auto p = m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 0);
-EXPECT_EQ(p.second, CompilerType());
+EXPECT_EQ(llvm::None,
+  m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 0));
 
 EXPECT_EQ(m_ast->GetTemplateArgumentKind(t.GetOpaqueQualType(), 1),
   eTemplateArgumentKindIntegral);
 EXPECT_EQ(m_ast->GetTypeTemplateArgument(t.GetOpaqueQualType(), 1),
   CompilerType());
-p = m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 1);
-EXPECT_EQ(p.first, llvm::APSInt(47));
-EXPECT_EQ(p.second, int_type);
+auto result = m_ast->GetIntegralTemplateArgument(t.GetOpaqueQualType(), 1);
+ASSERT_NE(llvm::None, result);
+EXPECT_EQ(arg, result->value);
+EXPECT_EQ(int_type, result->type);
   }
 }
Index: lldb/trunk/source/API/SBType.cpp
===
--- lldb/trunk/source/API/SBType.cpp
+++ lldb/trunk/source/API/SBType.cpp
@@ -426,7 +426,7 @@
 case eTemplateArgumentKindIntegral:
   type = m_opaque_sp->GetCompilerType(false)
  .GetIntegralTemplateArgument(idx)
- .second;
+ ->type;
   break;
 default:
   break;
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -7650,21 +7650,21 @@
   return CompilerType(getASTContext(), template_arg.getAsType());
 }
 
-std::pair
+llvm::Optional
 ClangASTContext::GetIntegralTemplateArgument(lldb::opaque_compiler_type_t type,
  size_t idx) {
   const clang::ClassTemplateSpecializationDecl *template_decl =
   GetAsTemplateSpecialization(type);
   if (! template_decl || idx >= template_decl->getTemplateArgs().size())
-return {llvm::APSInt(0), CompilerType()};
+return llvm::None;
 
   const clang::TemplateArgument &template_arg =
   template_decl->getTemplateArgs()[idx];
   if (template_arg.getKind() != clang::TemplateArgument::Integral)
-return {llvm::APSInt(0), CompilerType()};
+return llvm::None;
 
-  return {template_arg.getAsIntegral(),
-  CompilerType(getASTContext(), template_arg.getIntegralType())};
+  return {{template_arg.getAsIntegral(),
+   CompilerType(getASTContext(), template_arg.getIntegralType())}};
 }
 
 CompilerType ClangASTContext::GetTypeForFormatters(void *type) {
Index: lldb/trunk/source/Symbol/CompilerType.cpp
===
--- lldb/trunk/source/Symbol/CompilerType.cpp
+++ lldb/trunk/source/Symbol/CompilerType.cpp
@@ -703,12 +703,11 @@
   return CompilerType();
 }
 
-std::pair
-CompilerType::GetIntegralTemplateArgument(size_t idx) const
-{
+llvm::Optional
+CompilerType::GetIntegralTemplateArgument(size_t idx) const {
   if (IsValid())
 return m_type_system->GetIntegralTemplateArgument(m_type, idx);
-  return {llvm::APSInt(0), CompilerType()};
+  return llvm::None;
 }
 
 CompilerType CompilerType::GetTypeForFormatters() const {
Index: lldb/trunk/source/Symbol/TypeSystem.cpp
===
--- lldb/trunk/source/Symbol/TypeSystem.cpp
+++ lldb/trunk/source/Symbol/TypeSystem.cpp
@@ -111

[Lldb-commits] [PATCH] D40636: Create a trivial lldb-test program

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I feel this is reimplementing llvm-readobj, but maybe that's appropriate as we 
are reimplementing object file readers as well (my original patch wouldn't be 
necessary if we were using the llvm object library). Minor comments below, but 
I actually quite like this approach. It's also much less code than I expected 
this will need.




Comment at: lldb/tools/lldb-test/CMakeLists.txt:3
+(CMAKE_SYSTEM_NAME MATCHES "NetBSD" ))
+  # These targets do not have getopt support, so they rely on the one provided 
by
+  # liblldb. However, getopt is not a part of the liblldb interface, so we have

This is only scary if you link against liblldb, which you're not doing here. 
You also don't need to add lldbHost here, as it's already added in the list 
below. So this whole blob can just be deleted.



Comment at: lldb/tools/lldb-test/lldb-test.cpp:55
+  S->GetSectionData(Data);
+  llvm::outs() << "  Data: " << Data.GetCStr(&Offset) << "\n\n";
+}

My test case is probably the only place where this will actually be a real C 
string. I think we should go with something more generic like hex-encoding the 
data.


https://reviews.llvm.org/D40636



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

[Lldb-commits] [PATCH] D40647: Fix float expressions for PPC64le

[Alexandre Yukio Yamashita via Phabricator via lldb-commits]

alexandreyy created this revision.

Implemented FCmp and FPExt instructions.


https://reviews.llvm.org/D40647

Files:
  source/Expression/IRInterpreter.cpp

Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -217,7 +217,9 @@
 
 lldb_private::Scalar cast_scalar;
 
-if (!AssignToMatchType(cast_scalar, scalar.ULongLong(), value->getType()))
+if (value->getType()->isDoubleTy())
+  cast_scalar = scalar.Double();
+else if (!AssignToMatchType(cast_scalar, scalar.ULongLong(), value->getType()))
   return false;
 
 size_t value_byte_size = m_target_data.getTypeStoreSize(value->getType());
@@ -592,6 +594,8 @@
   } break;
   case Instruction::And:
   case Instruction::AShr:
+  case Instruction::FCmp:
+  case Instruction::FPExt:
   case Instruction::IntToPtr:
   case Instruction::PtrToInt:
   case Instruction::Load:
@@ -918,6 +922,34 @@
 
   frame.AssignValue(inst, S, module);
 } break;
+case Instruction::FPExt: {
+   const FPExtInst *cast_inst = dyn_cast(inst);
+
+   if (!cast_inst) {
+ if (log)
+   log->Printf(
+   "getOpcode() returns %s, but instruction is not a FPExtInst",
+   cast_inst->getOpcodeName());
+ error.SetErrorToGenericError();
+ error.SetErrorString(interpreter_internal_error);
+ return false;
+   }
+
+   Value *source = cast_inst->getOperand(0);
+
+   lldb_private::Scalar S;
+
+   if (!frame.EvaluateValue(S, source, module)) {
+ if (log)
+   log->Printf("Couldn't evaluate %s", PrintValue(source).c_str());
+ error.SetErrorToGenericError();
+ error.SetErrorString(bad_value_error);
+ return false;
+   }
+
+   lldb_private::Scalar S_Double(static_cast(S.Float()));
+   frame.AssignValue(inst, S_Double, module);
+} break;
 case Instruction::SExt: {
   const CastInst *cast_inst = dyn_cast(inst);
 
@@ -1104,20 +1136,38 @@
 log->Printf("  Poffset : %s", frame.SummarizeValue(inst).c_str());
   }
 } break;
+case Instruction::FCmp:
 case Instruction::ICmp: {
-  const ICmpInst *icmp_inst = dyn_cast(inst);
+  CmpInst::Predicate predicate;
 
-  if (!icmp_inst) {
-if (log)
+  char cmp_type = 0;
+  if (inst->getOpcode() == Instruction::FCmp) {
+const FCmpInst *fcmp_inst = dyn_cast(inst);
+
+if (fcmp_inst) {
+  predicate = fcmp_inst->getPredicate();
+  cmp_type = 'F';
+}
+  } else {
+const ICmpInst *icmp_inst = dyn_cast(inst);
+
+if (icmp_inst) {
+  predicate = icmp_inst->getPredicate();
+  cmp_type = 'I';
+}
+  }
+
+  if (! cmp_type) {
+if (log) {
   log->Printf(
-  "getOpcode() returns ICmp, but instruction is not an ICmpInst");
+  "getOpcode() returns %cCmp, but instruction is not an %cCmpInst",
+  cmp_type, cmp_type);
+}
 error.SetErrorToGenericError();
 error.SetErrorString(interpreter_internal_error);
 return false;
   }
 
-  CmpInst::Predicate predicate = icmp_inst->getPredicate();
-
   Value *lhs = inst->getOperand(0);
   Value *rhs = inst->getOperand(1);
 
@@ -1145,47 +1195,57 @@
   switch (predicate) {
   default:
 return false;
+  case CmpInst::FCMP_OEQ:
   case CmpInst::ICMP_EQ:
 result = (L == R);
 break;
+  case CmpInst::FCMP_ONE:
   case CmpInst::ICMP_NE:
 result = (L != R);
 break;
+  case CmpInst::FCMP_UGT:
   case CmpInst::ICMP_UGT:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L > R);
 break;
+  case CmpInst::FCMP_UGE:
   case CmpInst::ICMP_UGE:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L >= R);
 break;
+  case CmpInst::FCMP_ULT:
   case CmpInst::ICMP_ULT:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L < R);
 break;
+  case CmpInst::FCMP_ULE:
   case CmpInst::ICMP_ULE:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L <= R);
 break;
+  case CmpInst::FCMP_OGT:
   case CmpInst::ICMP_SGT:
 L.MakeSigned();
 R.MakeSigned();
 result = (L > R);
 break;
+  case CmpInst::FCMP_OGE:
   case CmpInst::ICMP_SGE:
 L.MakeSigned();
 R.MakeSigned();
 result = (L >= R);
 break;
+  case CmpInst::FCMP_OLT:
   case CmpInst::ICMP_SLT:
 L.MakeSigned();
 R.MakeSigned();
 result = (L < R);
 break;
+  case CmpInst::FCMP_OLE:
   case CmpInst::ICMP_SLE:
 L.MakeSigned();
 R.MakeSigned();
@@ -1196,7 +1256,7 @@
   frame.AssignValue(inst, result, modul

Re: [Lldb-commits] [PATCH] D40636: Create a trivial lldb-test program

[Zachary Turner via lldb-commits]

You’re right that it’s basically reimplementing readobj but as you said, we
have our own object file readers. More importantly though, even if we
delegated to llvm, something could still in theory go wrong in the Module
class.

Plus, the important thing part of this patch is not this one module
command, but everything else
On Thu, Nov 30, 2017 at 2:31 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:

> labath added a comment.
>
> I feel this is reimplementing llvm-readobj, but maybe that's appropriate
> as we are reimplementing object file readers as well (my original patch
> wouldn't be necessary if we were using the llvm object library). Minor
> comments below, but I actually quite like this approach. It's also much
> less code than I expected this will need.
>
>
>
> 
> Comment at: lldb/tools/lldb-test/CMakeLists.txt:3
> +(CMAKE_SYSTEM_NAME MATCHES "NetBSD" ))
> +  # These targets do not have getopt support, so they rely on the one
> provided by
> +  # liblldb. However, getopt is not a part of the liblldb interface, so
> we have
> 
> This is only scary if you link against liblldb, which you're not doing
> here. You also don't need to add lldbHost here, as it's already added in
> the list below. So this whole blob can just be deleted.
>
>
> 
> Comment at: lldb/tools/lldb-test/lldb-test.cpp:55
> +  S->GetSectionData(Data);
> +  llvm::outs() << "  Data: " << Data.GetCStr(&Offset) << "\n\n";
> +}
> 
> My test case is probably the only place where this will actually be a real
> C string. I think we should go with something more generic like
> hex-encoding the data.
>
>
> https://reviews.llvm.org/D40636
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D40616: ObjectFileELF: Add support for compressed sections

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 124926.
labath added a comment.

This rewrites the test in terms on the new lldb-test utility. It should be 
applied on top of https://reviews.llvm.org/D40636.

While doing that, I noticed a discrepancy in the data presented by the object
file interface -- for GetFileSize(), it would return the compressed size, but,
when reading the data, it would return the decompressed size. This seemed odd
and unwanted.

So now I fetch the decompressed size when constructing the Section object, and
make sure GetFileSize result matches what the GetSectionData returns. This is
slightly odd as well, because now if someone looks at individual section file
offsets and sizes, it will seem that multiple sections overlap. While
unfortunate, this is a situation that can arise in without the presence of
compressed sections (no linker will produce a file like that, but you can
certainly hand-craft one), and our elf parser will hapily accept these files.


https://reviews.llvm.org/D40616

Files:
  lit/CMakeLists.txt
  lit/Modules/compressed-sections.yaml
  lit/Modules/lit.local.cfg
  lit/lit.cfg
  lit/lit.site.cfg.in
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.h
  tools/lldb-test/lldb-test.cpp
  unittests/ObjectFile/ELF/TestObjectFileELF.cpp

Index: unittests/ObjectFile/ELF/TestObjectFileELF.cpp
===
--- unittests/ObjectFile/ELF/TestObjectFileELF.cpp
+++ unittests/ObjectFile/ELF/TestObjectFileELF.cpp
@@ -10,12 +10,13 @@
 
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
 #include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
+#include "TestingSupport/TestUtilities.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/HostInfo.h"
-#include "TestingSupport/TestUtilities.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/Support/Compression.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Program.h"
Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -47,12 +47,16 @@
   assert(S);
   llvm::outs() << "  Section " << I << "\n";
   llvm::outs() << "  Name: " << S->GetName().GetStringRef() << "\n";
-  llvm::outs() << "  Length: " << S->GetByteSize() << "\n";
+  llvm::outs() << "  VM size: " << S->GetByteSize() << "\n";
+  llvm::outs() << "  File size: " << S->GetFileSize() << "\n";
 
-  lldb::offset_t Offset = 0;
   DataExtractor Data;
   S->GetSectionData(Data);
-  llvm::outs() << "  Data: " << Data.GetCStr(&Offset) << "\n\n";
+  llvm::outs() << "  Data: ";
+  for (const uint8_t *B = Data.GetDataStart(); B < Data.GetDataEnd(); ++B)
+llvm::outs() << llvm::hexdigit(*B >> 4, true)
+ << llvm::hexdigit(*B & 0xf, true);
+  llvm::outs() << "\n\n";
 }
   }
 }
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -21,6 +21,7 @@
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/UUID.h"
 #include "lldb/lldb-private.h"
+#include "llvm/Object/Decompressor.h"
 
 #include "ELFHeader.h"
 
@@ -140,6 +141,9 @@
 
   ObjectFile::Strata CalculateStrata() override;
 
+  size_t ReadSectionData(lldb_private::Section *section,
+ lldb_private::DataExtractor §ion_data) override;
+
   // Returns number of program headers found in the ELF file.
   size_t GetProgramHeaderCount();
 
@@ -244,6 +248,11 @@
   /// Returns the number of headers parsed.
   size_t ParseSectionHeaders();
 
+  llvm::Expected
+  GetSectionDecompressor(const ELFSectionHeaderInfo §);
+
+  llvm::Expected GetSectionFileSize(const ELFSectionHeaderInfo §);
+
   static void ParseARMAttributes(lldb_private::DataExtractor &data,
  uint64_t length,
  lldb_private::ArchSpec &arch_spec);
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -23,6 +23,7 @@
 #include "lldb/Target/SectionLoadList.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
 #include "lldb/Utility/DataBufferLLVM.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/Status.h"
@@ -1814,7 +1815,38 @@
   return 0;
 }
 
+llvm::Expected
+ObjectFileELF::GetSectionDecompressor(const ELFSectionHeaderInfo §) {
+  const uint8_t *start = m_data.PeekData(sect.sh_offset, sect.sh_size);
+  if (!start)
+return llvm::make_error(
+"Invalid section file address or size.",

[Lldb-commits] [PATCH] D40474: DWZ 11/12: Main functionality

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil marked 2 inline comments as done.
jankratochvil added inline comments.



Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:487
+  public:
+// C++14: Use heterogenous lookup.
+DWZCommonFile(const lldb_private::FileSpec &filespec_ref);

jankratochvil wrote:
> labath wrote:
> > Have you looked at llvm::DenseSet? It already supports heterogenous lookup( 
> > `find_as(...)`). It can also be more efficient than unordered_set.
> `llvm::DenseSet` should do the trick, thanks.
"//The iterators in a DenseMap are invalidated whenever an insertion occurs, 
unlike map.//" - there is now `std::unordered_set` and a 
pointer to it by `DWZCommonFile *m_dwz_common_file;`.  So thanks for the hint 
but I do not find `DenseSet` to be applicable here.



https://reviews.llvm.org/D40474



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

Re: [Lldb-commits] [PATCH] D40616: ObjectFileELF: Add support for compressed sections

[Pavel Labath via lldb-commits]

I have to say I quite like how this test turned out to look like. In
terms of the last night's SBAPI vs. lldb-mi vs. whateever discussion,
i'd can say that there is nothing preventing this test written in
terms of the SB API. I didn't do it that way, because I have
automatically written the test at the same level as the code I was
modifying (which generally means the test is more light-weight and
focused), but since the SBModule/SBSection don't have much additional
logic themselves, it does not matter much in this case. However, I
agree that we don't want to restrict ourselves to the SB API here --
SB is good at providing a debugger API, but with this tool we are
explicitly not trying to test the debugger as a whole, but its
individual pieces.

And as far as lldb-mi goes, writing a test for this through lldb-mi
would quite challenging, as it is too high level. afaik (and I can't
say that I know much about lldb-mi) there is no lldb-mi primitive that
would let me read raw section data. And even if there was, I'd have to
be very careful in constructing the test object file, so that it would
look "valid enough" that lldb-mi would dare touch it.


On 30 November 2017 at 14:02, Pavel Labath via Phabricator
 wrote:
> labath updated this revision to Diff 124926.
> labath added a comment.
>
> This rewrites the test in terms on the new lldb-test utility. It should be 
> applied on top of https://reviews.llvm.org/D40636.
>
> While doing that, I noticed a discrepancy in the data presented by the object
> file interface -- for GetFileSize(), it would return the compressed size, but,
> when reading the data, it would return the decompressed size. This seemed odd
> and unwanted.
>
> So now I fetch the decompressed size when constructing the Section object, and
> make sure GetFileSize result matches what the GetSectionData returns. This is
> slightly odd as well, because now if someone looks at individual section file
> offsets and sizes, it will seem that multiple sections overlap. While
> unfortunate, this is a situation that can arise in without the presence of
> compressed sections (no linker will produce a file like that, but you can
> certainly hand-craft one), and our elf parser will hapily accept these files.
>
>
> https://reviews.llvm.org/D40616
>
> Files:
>   lit/CMakeLists.txt
>   lit/Modules/compressed-sections.yaml
>   lit/Modules/lit.local.cfg
>   lit/lit.cfg
>   lit/lit.site.cfg.in
>   source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
>   source/Plugins/ObjectFile/ELF/ObjectFileELF.h
>   tools/lldb-test/lldb-test.cpp
>   unittests/ObjectFile/ELF/TestObjectFileELF.cpp
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D40475#940226, @jankratochvil wrote:

> > you will probably be the only person who will be able to run these tests 
> > and verify dwz functionality.
>
> OK; really nobody runs RHEL/CentOS/Fedora? :-)


There aren't that many lldb developers... I wouldn't be surprised if the number 
of them having access to a red-hat machine is 1 (you).

> 
> 
>> If you don't setup a buildbot testing
> 
> OK, I will try that.  I was even running a test bot for GDB.
> 
>> These can range from checking in a couple of siple dwz files
> 
> OK; although during development various bugs required various testfiles, 
> single testfiles does not catch it all but sure better than nothing.
> 
>> reimplementing/upstreaming the utilities necessary to build dwz files 
>> ourselves (I am not sure what the dwz tool does, but the eu-strip and 
>> sepdebugcrcfix tools sound like they would be fairly easy to implement on 
>> top of existing llvm libraries).
> 
> DWZ has its upstream sources .
>  `eu-strip` is just a more optimized (and more ELF-details preserving) 
> variant of GNU binutils `strip`. It should be easy to slightly extend 
> `llvm-objcopy` (as there is no `llvm-strip`). Or is it OK to use GNU binutils 
> `strip` instead?
>  `sepdebugcrcfix` is a small utility currently inside upstream `rpm` package 
> so that could be reimplemented in LLVM.
>  Although I admit both `eu-strip` and `sepdebugcrcfix` are used in the LLDB 
> testsuite only to workaround some DWZ bug it fails for some reason to process 
> unsplit debug info. I did not find DWZ code convenient enough to bugfix it 
> there and its author Jakub Jelínek does not fix its reported bugs in recent 
> years.

It looks like it could be a fun project to reimplement `dwz` on top of llvm 
dwarf library, but I understand that would be a considerable detour for you.

> 
> 
>> The other thing that worries me is that your comments seem to indicate that 
>> not all dwz tests pass after this. Could you elaborate on the "Many ERRORs 
>> are correct" part and how you plan to rectify that?
> 
> There is never any Success->Failure case for _dwarf->_dwz (there were such 
> cases when I had bugs in my LLDB DWZ code).  But there are Success->Error 
> cases because in some cases DWZ tool cannot be used such as:
> 
>   os command: make MAKE_DSYM=NO DWZ=YES ARCH=x86_64 
> CC="/quad/home/jkratoch/redhat/llvm-git-build-release/bin/clang-6.0"
>   with pid: 14709
>   stdout:
>   stderr: dwz: a.out.debug.dwz: .debug_info section not present
>   make[4]: *** [../../make/Makefile.rules:538: a.out] Error 1
>   retcode: 2
>   ERROR
>   Error when building test subject.
> 
> 
> Unaware what to do with it. It could run the testcase without DWZ but then 
> the _dwarf testcase would be needlessly run twice. Or there could be a list 
> of tests to skip in DWZ mode. Or maybe some list of "ExpectedError" testcases 
> (I guess one cannot defined "ExpectedError" now). This also means `make 
> check-lldb` prints with DWZ a lot of error messages due to these "expected 
> Errors".

How many tests are we talking about here? Could you list them here? If these 
really don't produce any debug info, then we can probably just mark them as 
`@no_debug_info_testcase` (that prevents generating N versions of the same 
test) and be done with it. There is also the ability to skip a test for dwz 
explicitly.

Also, be aware that we don't really do a good job of distinguising errors and 
failures. Compilation problems are a common source of Errors, but other issues 
can come up as errors as well -- it just depends on details of how test is 
written.

>> your comments seem to indicate that not all regular dwarf tests were passing 
>> for you to begin with. Is that true?
> 
> Yes, I haven't investigated why yet.  I am used from GDB to only diff results 
> against regressions.  RESULT-clean/ 
>  or RESULT-clean.tar.xz 
> 

Yea, sometimes you have to do that here as well, but it's not a place where 
we'd like to be.
Looking at the results, they don't seem that bad, really. Most of the failures 
are in data formatters -- I think a well-placed `-fno-limit-debug-info` would 
get those working. The other category is something in the system library 
confusing the test (e.g. can't find `environ` or an extra global variable `c`). 
I think we could get those resolved fairly quickly.

BTW, is this on current master? I was hoping that some of these (such as 
TestTopLevelExpressions) would be resolved already.

> BTW with installed system debug info files (`/usr/lib/debug/**.debug`) the 
> LLDB testsuite times out and fails completely.  LLDB could have some option 
> like: `gdb -iex 'set debug-file-directory /notexists'`

Yea, that would be useful, particularly as we want to isolate the test from 
system specifics. It would also be useful to figure ou

Re: [Lldb-commits] [PATCH] D40616: ObjectFileELF: Add support for compressed sections

[Zachary Turner via lldb-commits]

Did you forget to add the new test to the changeset?
On Thu, Nov 30, 2017 at 6:19 AM Pavel Labath  wrote:

> I have to say I quite like how this test turned out to look like. In
> terms of the last night's SBAPI vs. lldb-mi vs. whateever discussion,
> i'd can say that there is nothing preventing this test written in
> terms of the SB API. I didn't do it that way, because I have
> automatically written the test at the same level as the code I was
> modifying (which generally means the test is more light-weight and
> focused), but since the SBModule/SBSection don't have much additional
> logic themselves, it does not matter much in this case. However, I
> agree that we don't want to restrict ourselves to the SB API here --
> SB is good at providing a debugger API, but with this tool we are
> explicitly not trying to test the debugger as a whole, but its
> individual pieces.
>
> And as far as lldb-mi goes, writing a test for this through lldb-mi
> would quite challenging, as it is too high level. afaik (and I can't
> say that I know much about lldb-mi) there is no lldb-mi primitive that
> would let me read raw section data. And even if there was, I'd have to
> be very careful in constructing the test object file, so that it would
> look "valid enough" that lldb-mi would dare touch it.
>
>
> On 30 November 2017 at 14:02, Pavel Labath via Phabricator
>  wrote:
> > labath updated this revision to Diff 124926.
> > labath added a comment.
> >
> > This rewrites the test in terms on the new lldb-test utility. It should
> be applied on top of https://reviews.llvm.org/D40636.
> >
> > While doing that, I noticed a discrepancy in the data presented by the
> object
> > file interface -- for GetFileSize(), it would return the compressed
> size, but,
> > when reading the data, it would return the decompressed size. This
> seemed odd
> > and unwanted.
> >
> > So now I fetch the decompressed size when constructing the Section
> object, and
> > make sure GetFileSize result matches what the GetSectionData returns.
> This is
> > slightly odd as well, because now if someone looks at individual section
> file
> > offsets and sizes, it will seem that multiple sections overlap. While
> > unfortunate, this is a situation that can arise in without the presence
> of
> > compressed sections (no linker will produce a file like that, but you can
> > certainly hand-craft one), and our elf parser will hapily accept these
> files.
> >
> >
> > https://reviews.llvm.org/D40616
> >
> > Files:
> >   lit/CMakeLists.txt
> >   lit/Modules/compressed-sections.yaml
> >   lit/Modules/lit.local.cfg
> >   lit/lit.cfg
> >   lit/lit.site.cfg.in
> >   source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
> >   source/Plugins/ObjectFile/ELF/ObjectFileELF.h
> >   tools/lldb-test/lldb-test.cpp
> >   unittests/ObjectFile/ELF/TestObjectFileELF.cpp
> >
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D40616: ObjectFileELF: Add support for compressed sections

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t

It's right here. (I'm open to suggestions where to place it).


https://reviews.llvm.org/D40616



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

[Lldb-commits] [lldb] r319443 - Add a test case for open bug 35480

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu Nov 30 07:39:57 2017
New Revision: 319443

URL: http://llvm.org/viewvc/llvm-project?rev=319443&view=rev
Log:
Add a test case for open bug 35480

The test is about failing to hit breakpoints in global constructors in
shared libraries.

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile?rev=319443&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
 Thu Nov 30 07:39:57 2017
@@ -0,0 +1,8 @@
+LEVEL = ../../../make
+
+DYLIB_NAME := foo
+DYLIB_CXX_SOURCES := foo.cpp
+CXX_SOURCES := main.cpp
+CFLAGS_EXTRAS := -fPIC
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py?rev=319443&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
 Thu Nov 30 07:39:57 2017
@@ -0,0 +1,46 @@
+"""
+Test that we can hit breakpoints in global constructors
+"""
+
+from __future__ import print_function
+
+
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestBreakpointInGlobalConstructors(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+TestBase.setUp(self)
+self.line_foo = line_number('foo.cpp', '// !BR_foo')
+self.line_main = line_number('main.cpp', '// !BR_main')
+
+@expectedFailureAll(bugnumber="llvm.org/pr35480", oslist=["linux"])
+def test(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+self.runCmd("file %s" % exe)
+
+bp_main = lldbutil.run_break_set_by_file_and_line(
+self, 'main.cpp', self.line_main)
+bp_foo = lldbutil.run_break_set_by_file_and_line(
+self, 'foo.cpp', self.line_foo)
+
+self.runCmd("run")
+
+self.assertIsNotNone(
+lldbutil.get_one_thread_stopped_at_breakpoint_id(
+self.process(), bp_foo))
+
+self.runCmd("continue")
+
+self.assertIsNotNone(
+lldbutil.get_one_thread_stopped_at_breakpoint_id(
+self.process(), bp_main))

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp?rev=319443&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
 Thu Nov 30 07:39:57 2017
@@ -0,0 +1,5 @@
+#include "foo.h"
+
+Foo::Foo() : x(42) {} // !BR_foo
+
+Foo FooObj;

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h?rev=319443&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h
 Thu Nov 30 07:39:57 2017
@@ -0,0 +1,11 @@
+#ifndef FOO_H
+#define FOO_H
+
+struct LLDB

[Lldb-commits] [PATCH] D40647: Fix float expressions for PPC64le

[Alexandre Yukio Yamashita via Phabricator via lldb-commits]

alexandreyy updated this revision to Diff 124952.
alexandreyy added a comment.

Add SIToFP and UIToFP instructions to handle comparisons between float and char 
values.


https://reviews.llvm.org/D40647

Files:
  source/Expression/IRInterpreter.cpp

Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -217,7 +217,9 @@
 
 lldb_private::Scalar cast_scalar;
 
-if (!AssignToMatchType(cast_scalar, scalar.ULongLong(), value->getType()))
+if (value->getType()->isDoubleTy())
+  cast_scalar = scalar.Double();
+else if (!AssignToMatchType(cast_scalar, scalar.ULongLong(), value->getType()))
   return false;
 
 size_t value_byte_size = m_target_data.getTypeStoreSize(value->getType());
@@ -592,6 +594,8 @@
   } break;
   case Instruction::And:
   case Instruction::AShr:
+  case Instruction::FCmp:
+  case Instruction::FPExt:
   case Instruction::IntToPtr:
   case Instruction::PtrToInt:
   case Instruction::Load:
@@ -602,12 +606,14 @@
   case Instruction::SDiv:
   case Instruction::SExt:
   case Instruction::Shl:
+  case Instruction::SIToFP:
   case Instruction::SRem:
   case Instruction::Store:
   case Instruction::Sub:
   case Instruction::Trunc:
   case Instruction::UDiv:
   case Instruction::URem:
+  case Instruction::UIToFP:
   case Instruction::Xor:
   case Instruction::ZExt:
 break;
@@ -918,6 +924,51 @@
 
   frame.AssignValue(inst, S, module);
 } break;
+case Instruction::FPExt:
+case Instruction::SIToFP:
+case Instruction::UIToFP: {
+   const CastInst *cast_inst = dyn_cast(inst);
+
+   if (!cast_inst) {
+ if (log)
+   log->Printf("Instruction is not a CastInst");
+ error.SetErrorToGenericError();
+ error.SetErrorString(interpreter_internal_error);
+ return false;
+   }
+
+   Value *source = cast_inst->getOperand(0);
+
+   lldb_private::Scalar S;
+
+   if (!frame.EvaluateValue(S, source, module)) {
+ if (log)
+   log->Printf("Couldn't evaluate %s", PrintValue(source).c_str());
+ error.SetErrorToGenericError();
+ error.SetErrorString(bad_value_error);
+ return false;
+   }
+
+   lldb_private::Scalar result;
+   double result_double;
+
+   switch (inst->getOpcode()) {
+   default:
+ break;
+   case Instruction::FPExt:
+ result_double = static_cast(S.Float());
+ break;
+   case Instruction::SIToFP:
+ result_double = static_cast(S.SInt());
+ break;
+   case Instruction::UIToFP:
+ result_double = static_cast(S.UInt());
+ break;
+   }
+
+   lldb_private::Scalar Scalar_Double(result_double);
+   frame.AssignValue(inst, Scalar_Double, module);
+} break;
 case Instruction::SExt: {
   const CastInst *cast_inst = dyn_cast(inst);
 
@@ -1104,20 +1155,38 @@
 log->Printf("  Poffset : %s", frame.SummarizeValue(inst).c_str());
   }
 } break;
+case Instruction::FCmp:
 case Instruction::ICmp: {
-  const ICmpInst *icmp_inst = dyn_cast(inst);
+  CmpInst::Predicate predicate;
 
-  if (!icmp_inst) {
-if (log)
+  char cmp_type = 0;
+  if (inst->getOpcode() == Instruction::FCmp) {
+const FCmpInst *fcmp_inst = dyn_cast(inst);
+
+if (fcmp_inst) {
+  predicate = fcmp_inst->getPredicate();
+  cmp_type = 'F';
+}
+  } else {
+const ICmpInst *icmp_inst = dyn_cast(inst);
+
+if (icmp_inst) {
+  predicate = icmp_inst->getPredicate();
+  cmp_type = 'I';
+}
+  }
+
+  if (! cmp_type) {
+if (log) {
   log->Printf(
-  "getOpcode() returns ICmp, but instruction is not an ICmpInst");
+  "getOpcode() returns %cCmp, but instruction is not an %cCmpInst",
+  cmp_type, cmp_type);
+}
 error.SetErrorToGenericError();
 error.SetErrorString(interpreter_internal_error);
 return false;
   }
 
-  CmpInst::Predicate predicate = icmp_inst->getPredicate();
-
   Value *lhs = inst->getOperand(0);
   Value *rhs = inst->getOperand(1);
 
@@ -1145,47 +1214,57 @@
   switch (predicate) {
   default:
 return false;
+  case CmpInst::FCMP_OEQ:
   case CmpInst::ICMP_EQ:
 result = (L == R);
 break;
+  case CmpInst::FCMP_ONE:
   case CmpInst::ICMP_NE:
 result = (L != R);
 break;
+  case CmpInst::FCMP_UGT:
   case CmpInst::ICMP_UGT:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L > R);
 break;
+  case CmpInst::FCMP_UGE:
   case CmpInst::ICMP_UGE:
 L.MakeUnsigned();
 R.MakeUnsigned();
 result = (L >= R);
 break;
+  

[Lldb-commits] [PATCH] D40616: ObjectFileELF: Add support for compressed sections

[Zachary Turner via Phabricator via lldb-commits]

zturner added inline comments.



Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t

labath wrote:
> It's right here. (I'm open to suggestions where to place it).
I see.  I think part of the reason I didn't notice it is because it has a 
`.yaml` extension just like the old one, so I didn't notice this was really a 
test.

LLVM is a little inconsistent here (it has tests that end in `.ll` and `.s`, 
but not for most other file extensions), so can you rename this to 
`compressed-sections.test`?

At some point I think we should inject another directory in this hierarchy 
(i.e. `lit/test/Modules`), but since this is not going to be the first 
directory here, I guess it doesn't need to happen now.



Comment at: lit/Modules/compressed-sections.yaml:12-13
+  - Name:.hello_elf
+# CHECK: Section 1
+# CHECK: Name: .hello_elf
+Type:SHT_PROGBITS

Can you separate the `CHECK` lines and the YAML content?  I think it makes it 
easier to follow this way, and it gives a consistent paradigm (checks first, 
then input, or vice versa).  Interspersing them doesn't always work (for 
example if the tool doesn't output things in the same order as the input 
description).





Comment at: lit/Modules/compressed-sections.yaml:17-18
+Content: 010008000100789c533070084828689809c802c1
+# CHECK: File size: 8
+# CHECK: Data: 2030405060708090
+  - Name:.bogus

Can you use `CHECK-NEXT` for these two?  As it stands, if we output:

```
Name: .hello_elf
File size: -1
Data: -1

Name: .hello_coff
File size: 8
Data: 2030405060708090
```

It would pass, as written.



Comment at: lit/Modules/compressed-sections.yaml:20
+  - Name:.bogus
+# CHECK-NOT: .bogus
+Type:SHT_PROGBITS

You should probably put this as the very first check statement.  Each 
successfully matching `CHECK` line will update an internal position and 
subsequent checks will only start from that position, so here you're only 
checking that after `.bogus` does not occur after `.hello_elf`, but this test 
would pass if `.bogus` occurred before `.hello_elf`.  But putting the 
`CHECK-NOT` first, both will fail  (this is also a good reason not to 
intersperse the check lines).


https://reviews.llvm.org/D40616



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

[Lldb-commits] [PATCH] D40636: Create a trivial lldb-test program

[Zachary Turner via Phabricator via lldb-commits]

zturner updated this revision to Diff 124960.
zturner added a comment.

Updated based on labath@'s suggestions.  Also added a new class `LinePrinter`, 
shamelessly ripped and stripped down from a copy used in one of LLVM's dumpers, 
but that makes it possible to do some nice formatting easily.


https://reviews.llvm.org/D40636

Files:
  lldb/tools/CMakeLists.txt
  lldb/tools/lldb-test/CMakeLists.txt
  lldb/tools/lldb-test/FormatUtil.cpp
  lldb/tools/lldb-test/FormatUtil.h
  lldb/tools/lldb-test/SystemInitializerTest.cpp
  lldb/tools/lldb-test/SystemInitializerTest.h
  lldb/tools/lldb-test/lldb-test.cpp

Index: lldb/tools/lldb-test/lldb-test.cpp
===
--- /dev/null
+++ lldb/tools/lldb-test/lldb-test.cpp
@@ -0,0 +1,98 @@
+//===- lldb-test.cpp -- *- C++ --*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "FormatUtil.h"
+#include "SystemInitializerTest.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Initialization/SystemLifetimeManager.h"
+#include "lldb/Utility/DataExtractor.h"
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/PrettyStackTrace.h"
+#include "llvm/Support/Signals.h"
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace llvm;
+
+namespace opts {
+cl::SubCommand ModuleSubcommand("module-sections",
+"Display LLDB Module Information");
+
+namespace module {
+cl::opt SectionContents("contents",
+  cl::desc("Dump each section's contents"),
+  cl::sub(ModuleSubcommand));
+cl::list InputFilenames(cl::Positional, cl::desc(""),
+ cl::OneOrMore, cl::sub(ModuleSubcommand));
+} // namespace module
+} // namespace opts
+
+static llvm::ManagedStatic DebuggerLifetime;
+
+static void dumpModules(Debugger &Dbg) {
+  LinePrinter Printer(4, llvm::outs());
+
+  for (const auto &File : opts::module::InputFilenames) {
+ModuleSpec Spec{FileSpec(File, false)};
+Spec.GetSymbolFileSpec().SetFile(File, false);
+
+auto ModulePtr = std::make_shared(Spec);
+SectionList *Sections = ModulePtr->GetSectionList();
+if (!Sections) {
+  llvm::errs() << "Could not load sections for module " << File << "\n";
+  continue;
+}
+
+size_t Count = Sections->GetNumSections(0);
+Printer.formatLine("Showing {0} sections", Count);
+for (size_t I = 0; I < Count; ++I) {
+  AutoIndent Indent(Printer, 2);
+  auto S = Sections->GetSectionAtIndex(I);
+  assert(S);
+  Printer.formatLine("Index: {0}", I);
+  Printer.formatLine("Name: {0}", S->GetName().GetStringRef());
+  Printer.formatLine("Length: {0}", S->GetByteSize());
+
+  if (opts::module::SectionContents) {
+DataExtractor Data;
+S->GetSectionData(Data);
+ArrayRef Bytes = {Data.GetDataStart(), Data.GetDataEnd()};
+Printer.formatBinary("Data: ", Bytes, 0);
+  }
+  Printer.NewLine();
+}
+  }
+}
+
+int main(int argc, const char *argv[]) {
+  StringRef ToolName = argv[0];
+  sys::PrintStackTraceOnErrorSignal(ToolName);
+  PrettyStackTraceProgram X(argc, argv);
+  llvm_shutdown_obj Y;
+
+  cl::ParseCommandLineOptions(argc, argv, "LLDB Testing Utility\n");
+
+  DebuggerLifetime->Initialize(llvm::make_unique(),
+   nullptr);
+
+  auto Dbg = lldb_private::Debugger::CreateInstance();
+
+  if (opts::ModuleSubcommand)
+dumpModules(*Dbg);
+
+  DebuggerLifetime->Terminate();
+  return 0;
+}
Index: lldb/tools/lldb-test/SystemInitializerTest.h
===
--- /dev/null
+++ lldb/tools/lldb-test/SystemInitializerTest.h
@@ -0,0 +1,35 @@
+//===-- SystemInitializerTest.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLDB_API_SYSTEM_INITIALIZER_TEST_H
+#define LLDB_API_SYSTEM_INITIALIZER_TEST_H
+
+#include "lldb/Initialization/SystemInitializerCommon.h"
+
+namespace lldb_private {
+//--
+/// Initializes lldb.
+///
+/// This class is responsible for initializing all of lldb system
+/// services needed to use the full LLDB application.  This class is
+/// not intended to be used externally, but is instead used
+/// internally by SBDebugger 

[Lldb-commits] [lldb] r319454 - Remove a long out-of-date comment.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Nov 30 10:35:35 2017
New Revision: 319454

URL: http://llvm.org/viewvc/llvm-project?rev=319454&view=rev
Log:
Remove a long out-of-date comment.

Modified:
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=319454&r1=319453&r2=319454&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Thu Nov 30 10:35:35 2017
@@ -1560,7 +1560,6 @@ uint32_t Process::AssignIndexIDToThread(
 }
 
 StateType Process::GetState() {
-  // If any other threads access this we will need a mutex for it
   return m_public_state.GetValue();
 }
 


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

[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Davide Italiano via Phabricator via lldb-commits]

davide added a comment.

@jankratochvil I run Fedora for now on my desktop, but I don't have time and 
resources to devote to a buildbot.
IMHO, having a fedora bot would be a great thing for two reasons:

1. I found out Fedora exposes bugs that ubuntu doesn't (e.g. in symbol 
resolution, due to slightly different naming for globals in shared libraries)
2. We can improve coverage for Linux for lldb.

I think the first step to get this to work is to get the build green there, and 
then we can iterate, if you're interested.


https://reviews.llvm.org/D40475



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

Re: [Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Jim Ingham via lldb-commits]

We had a similar problem with the tests on macOS.  lldb has a facility that 
will do automatic lookup of UUID -> dSYM (macOS's separate debug info format) 
and if you are internal to Apple this will find all the system library debug 
info.  That will cause a handful of tests to fail, mostly because the presence 
of debug information changes stepping behavior.  doTest.py has a method: 
"checkDsymForUUIDIsNotOn" to ensure that this facility is turned off and if it 
is not will warn you and abort the test run.

You are going to have to do something of that sort even once you get reading 
these libraries in to work, so I agree a setting seems like a good idea.  There 
is a setting for debug file search paths: target.debug-file-search-paths but 
I'd rather not add a special cookie to that since you can imagine wanting to 
point to a directory with your debug info and ALSO not read in the system debug 
info.  So it would be better IMO to add a parallel debug-file-avoid-directory 
setting.  

Jim
 

> On Nov 30, 2017, at 6:57 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
>> BTW with installed system debug info files (`/usr/lib/debug/**.debug`) the 
>> LLDB testsuite times out and fails completely.  LLDB could have some option 
>> like: `gdb -iex 'set debug-file-directory /notexists'`
> 
> Yea, that would be useful, particularly as we want to isolate the test from 
> system specifics. It would also be useful to figure out why does it hang, as 
> it will probably affect your users as well. :)
> 

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

[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D40475#935615, @labath wrote:

> The thing to be aware of with this testing strategy is that you will probably 
> be the only person who will be able to run these tests and verify dwz 
> functionality. If you don't setup a buildbot testing this then other 
> developers will never even know if they have broken any dwz functionality in 
> the future. While end-to-end tests are great and we need them, I think it 
> would be worthwhile to think about other testing strategies. These can range 
> from checking in a couple of siple dwz files and making sure we can extract 
> information from them (see unittests/SymbolFile/PDB for code that does 
> something similar) to reimplementing/upstreaming the utilities necessary to 
> build dwz files ourselves (I am not sure what the `dwz` tool does, but the 
> `eu-strip` and `sepdebugcrcfix` tools sound like they would be fairly easy to 
> implement on top of existing llvm libraries).
>
> The other thing that worries me is that your comments seem to indicate that 
> not all dwz tests pass after this. Could you elaborate on the "Many ERRORs 
> are correct" part and how you plan to rectify that?
>
> The third thing I want to say is not really related to your patchset, but 
> your comments seem to indicate that not all regular dwarf tests were passing 
> for you to begin with. Is that true? Would you be willing to help me 
> (probably in a separate thread) to identify the tests that are failing and 
> why? I'd like to move us towards a state where the result of the tests does 
> not depend on the system you're running on and people don't have to resort to 
> differential comparisons.


With the forthcoming introduction of `lldb-test`, why don't we piggyback off of 
that?  We already have a compiler, so use it to produce a `dwz`, and then use 
`lldb-test` to exercise something about it.  It won't be as comprehensive as a 
full scale test, but it would be a nice complement.  We'd have basic test 
coverage on all platforms right out of the gate.


https://reviews.llvm.org/D40475



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

Re: [Lldb-commits] [lldb] r319443 - Add a test case for open bug 35480

[Jim Ingham via lldb-commits]

This test actually almost succeeds on macOS.  The problem is that your 
breakpoint in the Foo constructor produces two line table entries so we hit the 
foo breakpoint twice.  If you change the test file to:

Index: 
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
===
--- 
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
(revision 319461)
+++ 
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
(working copy)
@@ -1,5 +1,7 @@
 #include "foo.h"
 
-Foo::Foo() : x(42) {} // !BR_foo
+Foo::Foo() : x(42) {
+bool some_code = x == 42;  // !BR_foo
+} 
 
 Foo FooObj;

then there is only one location and we do hit that breakpoint and the test 
succeeds.

Jim

> On Nov 30, 2017, at 7:39 AM, Pavel Labath via lldb-commits 
>  wrote:
> 
> Author: labath
> Date: Thu Nov 30 07:39:57 2017
> New Revision: 319443
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=319443&view=rev
> Log:
> Add a test case for open bug 35480
> 
> The test is about failing to hit breakpoints in global constructors in
> shared libraries.
> 
> Added:
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp
> 
> Added: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile?rev=319443&view=auto
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>  (added)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>  Thu Nov 30 07:39:57 2017
> @@ -0,0 +1,8 @@
> +LEVEL = ../../../make
> +
> +DYLIB_NAME := foo
> +DYLIB_CXX_SOURCES := foo.cpp
> +CXX_SOURCES := main.cpp
> +CFLAGS_EXTRAS := -fPIC
> +
> +include $(LEVEL)/Makefile.rules
> 
> Added: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py?rev=319443&view=auto
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>  (added)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>  Thu Nov 30 07:39:57 2017
> @@ -0,0 +1,46 @@
> +"""
> +Test that we can hit breakpoints in global constructors
> +"""
> +
> +from __future__ import print_function
> +
> +
> +import os
> +import lldb
> +from lldbsuite.test.decorators import *
> +from lldbsuite.test.lldbtest import *
> +from lldbsuite.test import lldbutil
> +
> +
> +class TestBreakpointInGlobalConstructors(TestBase):
> +
> +mydir = TestBase.compute_mydir(__file__)
> +NO_DEBUG_INFO_TESTCASE = True
> +
> +def setUp(self):
> +TestBase.setUp(self)
> +self.line_foo = line_number('foo.cpp', '// !BR_foo')
> +self.line_main = line_number('main.cpp', '// !BR_main')
> +
> +@expectedFailureAll(bugnumber="llvm.org/pr35480", oslist=["linux"])
> +def test(self):
> +self.build()
> +exe = os.path.join(os.getcwd(), "a.out")
> +self.runCmd("file %s" % exe)
> +
> +bp_main = lldbutil.run_break_set_by_file_and_line(
> +self, 'main.cpp', self.line_main)
> +bp_foo = lldbutil.run_break_set_by_file_and_line(
> +self, 'foo.cpp', self.line_foo)
> +
> +self.runCmd("run")
> +
> +self.assertIsNotNone(
> +lldbutil.get_one_thread_stopped_at_breakpoint_id(
> +self.process(), bp_foo))
> +
> +self.runCmd("continue")
> +
> +self.assertIsNotNone(
> +lldbutil.get_one_thread_stopped_at_breakpoint_id(
> +self.process(), bp_main))
> 
> Added: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/package

Re: [Lldb-commits] [lldb] r319443 - Add a test case for open bug 35480

[Jim Ingham via lldb-commits]

The other way to do this would be to pass num_expected_locations = -1 when you 
make the foo breakpoint, and then grab the breakpoint's number of locations and 
assume you are going to hit the breakpoint that many times.

But changing the code so that the line you are breaking on is unambiguously one 
piece of code is simpler.

Jim


> On Nov 30, 2017, at 11:26 AM, Jim Ingham  wrote:
> 
> This test actually almost succeeds on macOS.  The problem is that your 
> breakpoint in the Foo constructor produces two line table entries so we hit 
> the foo breakpoint twice.  If you change the test file to:
> 
> Index: 
> packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
> ===
> --- 
> packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
>   (revision 319461)
> +++ 
> packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
>   (working copy)
> @@ -1,5 +1,7 @@
> #include "foo.h"
> 
> -Foo::Foo() : x(42) {} // !BR_foo
> +Foo::Foo() : x(42) {
> +bool some_code = x == 42;  // !BR_foo
> +} 
> 
> Foo FooObj;
> 
> then there is only one location and we do hit that breakpoint and the test 
> succeeds.
> 
> Jim
> 
>> On Nov 30, 2017, at 7:39 AM, Pavel Labath via lldb-commits 
>>  wrote:
>> 
>> Author: labath
>> Date: Thu Nov 30 07:39:57 2017
>> New Revision: 319443
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=319443&view=rev
>> Log:
>> Add a test case for open bug 35480
>> 
>> The test is about failing to hit breakpoints in global constructors in
>> shared libraries.
>> 
>> Added:
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.h
>>   
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp
>> 
>> Added: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile?rev=319443&view=auto
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>>  (added)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/Makefile
>>  Thu Nov 30 07:39:57 2017
>> @@ -0,0 +1,8 @@
>> +LEVEL = ../../../make
>> +
>> +DYLIB_NAME := foo
>> +DYLIB_CXX_SOURCES := foo.cpp
>> +CXX_SOURCES := main.cpp
>> +CFLAGS_EXTRAS := -fPIC
>> +
>> +include $(LEVEL)/Makefile.rules
>> 
>> Added: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py?rev=319443&view=auto
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>>  (added)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/TestBreakpointInGlobalConstructor.py
>>  Thu Nov 30 07:39:57 2017
>> @@ -0,0 +1,46 @@
>> +"""
>> +Test that we can hit breakpoints in global constructors
>> +"""
>> +
>> +from __future__ import print_function
>> +
>> +
>> +import os
>> +import lldb
>> +from lldbsuite.test.decorators import *
>> +from lldbsuite.test.lldbtest import *
>> +from lldbsuite.test import lldbutil
>> +
>> +
>> +class TestBreakpointInGlobalConstructors(TestBase):
>> +
>> +mydir = TestBase.compute_mydir(__file__)
>> +NO_DEBUG_INFO_TESTCASE = True
>> +
>> +def setUp(self):
>> +TestBase.setUp(self)
>> +self.line_foo = line_number('foo.cpp', '// !BR_foo')
>> +self.line_main = line_number('main.cpp', '// !BR_main')
>> +
>> +@expectedFailureAll(bugnumber="llvm.org/pr35480", oslist=["linux"])
>> +def test(self):
>> +self.build()
>> +exe = os.path.join(os.getcwd(), "a.out")
>> +self.runCmd("file %s" % exe)
>> +
>> +bp_main = lldbutil.run_break_set_by_file_and_line(
>> +self, 'main.cpp', self.line_main)
>> +bp_foo = lldbutil.run_break_set_by_file_and_line(
>> +self, 'foo.cpp', self.line_foo)
>> +
>> + 

[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In https://reviews.llvm.org/D40475#940462, @labath wrote:

> It looks like it could be a fun project to reimplement `dwz` on top of llvm 
> dwarf library, but I understand that would be a considerable detour for you.


I think it would be best to drop DWZ, IIRC its gain is not much bigger than 
`-fdebug-types-section` and it is incompatible with some 3rd party debug info 
tools as DWZ did not really became a standard.  I just want to make LLDB 
compatible with it.

> How many tests are we talking about here? Could you list them here?

These tests ERROR due to `dwz: a.out.debug.dwz: .debug_info section not 
present`:

  
functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py
  
functionalities/data-formatter/data-formatter-ptr-to-array/TestPtrToArrayFormatting.py
  functionalities/data-formatter/ptr_ref_typedef/TestPtrRef2Typedef.py
  functionalities/data-formatter/typedef_array/TestTypedefArray.py
  functionalities/frame_var_scope/TestFrameVariableScope.py
  functionalities/signal/TestSendSignal.py
  lang/cpp/bool/TestCPPBool.py
  lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  lang/cpp/lambdas/TestLambdas.py
  lang/cpp/nsimport/TestCppNsImport.py
  linux/builtin_trap/TestBuiltinTrap.py
  python_api/rdar-12481949/Test-rdar-12481949.py
  sample_test/TestSampleInlineTest.py



> If these really don't produce any debug info, then we can probably just mark 
> them as `@no_debug_info_testcase`

I do not see this keyword in the tree.

> Looking at the results, they don't seem that bad, really. Most of the 
> failures are in data formatters -- I think a well-placed 
> `-fno-limit-debug-info` would get those working. The other category is 
> something in the system library confusing the test (e.g. can't find `environ` 
> or an extra global variable `c`). I think we could get those resolved fairly 
> quickly.
> 
> BTW, is this on current master? I was hoping that some of these (such as 
> TestTopLevelExpressions) would be resolved already.

No, it was from 26th.  I have refreshed the files with today's GIT hash 
`6513119854292f1992c95073e99d55bf88456adb` = SVN `319402`.

> It would also be useful to figure out why does it hang, as it will probably 
> affect your users as well. :)

I expect because LLDB does not have any Linux DWARF index support, it has only 
some Apple OSX index support. GDB's `.debug_index` is not usable for LLDB as it 
does not contain DIE offsets. I would like to implement DWARF-5 `.debug_names` 
for it later.


https://reviews.llvm.org/D40475



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

[Lldb-commits] [lldb] r319472 - Fix this test so that the breakpoints you set are

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Nov 30 12:43:00 2017
New Revision: 319472

URL: http://llvm.org/viewvc/llvm-project?rev=319472&view=rev
Log:
Fix this test so that the breakpoints you set are
unambiguously on one bit of code.  On macOS these
lines mapped to two distinct locations, and that
was artificially throwing off the test.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp?rev=319472&r1=319471&r2=319472&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.cpp
 Thu Nov 30 12:43:00 2017
@@ -1,5 +1,7 @@
 #include "foo.h"
 
-Foo::Foo() : x(42) {} // !BR_foo
+Foo::Foo() : x(42) {
+bool some_code = x == 42;  // !BR_foo
+} 
 
 Foo FooObj;

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp?rev=319472&r1=319471&r2=319472&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/main.cpp
 Thu Nov 30 12:43:00 2017
@@ -5,7 +5,9 @@ struct Main {
   int x;
 };
 
-Main::Main() : x(47) {} // !BR_main
+Main::Main() : x(47) {
+bool some_code = x == 47; // !BR_main
+}
 
 Main MainObj;
 


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

[Lldb-commits] [PATCH] D40587: [lldb] Minor fixes in TaskPool

[Alexander Shaposhnikov via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL319492: [lldb] A few minor fixes in TaskPool (authored by 
alexshap).

Changed prior to commit:
  https://reviews.llvm.org/D40587?vs=124661&id=125036#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D40587

Files:
  lldb/trunk/include/lldb/Host/TaskPool.h
  lldb/trunk/source/Host/common/TaskPool.cpp
  lldb/trunk/unittests/Host/TaskPoolTest.cpp


Index: lldb/trunk/unittests/Host/TaskPoolTest.cpp
===
--- lldb/trunk/unittests/Host/TaskPoolTest.cpp
+++ lldb/trunk/unittests/Host/TaskPoolTest.cpp
@@ -2,6 +2,8 @@
 
 #include "lldb/Host/TaskPool.h"
 
+using namespace lldb_private;
+
 TEST(TaskPoolTest, AddTask) {
   auto fn = [](int x) { return x * x + 1; };
 
Index: lldb/trunk/source/Host/common/TaskPool.cpp
===
--- lldb/trunk/source/Host/common/TaskPool.cpp
+++ lldb/trunk/source/Host/common/TaskPool.cpp
@@ -14,6 +14,8 @@
 #include// for queue
 #include   // for thread
 
+namespace lldb_private {
+
 namespace {
 class TaskPoolImpl {
 public:
@@ -46,13 +48,20 @@
 
 TaskPoolImpl::TaskPoolImpl() : m_thread_count(0) {}
 
+unsigned GetHardwareConcurrencyHint() {
+  // std::thread::hardware_concurrency may return 0
+  // if the value is not well defined or not computable.
+  static const unsigned g_hardware_concurrency = 
+std::max(1u, std::thread::hardware_concurrency());
+  return g_hardware_concurrency;
+}
+
 void TaskPoolImpl::AddTask(std::function &&task_fn) {
-  static const uint32_t max_threads = std::thread::hardware_concurrency();
   const size_t min_stack_size = 8 * 1024 * 1024;
 
   std::unique_lock lock(m_tasks_mutex);
   m_tasks.emplace(std::move(task_fn));
-  if (m_thread_count < max_threads) {
+  if (m_thread_count < GetHardwareConcurrencyHint()) {
 m_thread_count++;
 // Note that this detach call needs to happen with the m_tasks_mutex held.
 // This prevents the thread
@@ -77,7 +86,7 @@
   break;
 }
 
-std::function f = pool->m_tasks.front();
+std::function f = std::move(pool->m_tasks.front());
 pool->m_tasks.pop();
 lock.unlock();
 
@@ -87,10 +96,9 @@
 
 void TaskMapOverInt(size_t begin, size_t end,
 const llvm::function_ref &func) {
+  const size_t num_workers = std::min(end, 
GetHardwareConcurrencyHint());
   std::atomic idx{begin};
-  size_t num_workers =
-  std::min(end, std::thread::hardware_concurrency());
-
+  
   auto wrapper = [&idx, end, &func]() {
 while (true) {
   size_t i = idx.fetch_add(1);
@@ -107,3 +115,6 @@
   for (size_t i = 0; i < num_workers; i++)
 futures[i].wait();
 }
+
+} // namespace lldb_private
+
Index: lldb/trunk/include/lldb/Host/TaskPool.h
===
--- lldb/trunk/include/lldb/Host/TaskPool.h
+++ lldb/trunk/include/lldb/Host/TaskPool.h
@@ -18,6 +18,8 @@
 #include// for mutex, unique_lock, condition_variable
 #include  // for forward, result_of, move
 
+namespace lldb_private {
+
 // Global TaskPool class for running tasks in parallel on a set of worker 
thread
 // created the first
 // time the task pool is used. The TaskPool provide no guarantee about the 
order
@@ -89,4 +91,8 @@
 void TaskMapOverInt(size_t begin, size_t end,
 const llvm::function_ref &func);
 
+unsigned GetHardwareConcurrencyHint();
+
+} // namespace lldb_private
+
 #endif // #ifndef utility_TaskPool_h_


Index: lldb/trunk/unittests/Host/TaskPoolTest.cpp
===
--- lldb/trunk/unittests/Host/TaskPoolTest.cpp
+++ lldb/trunk/unittests/Host/TaskPoolTest.cpp
@@ -2,6 +2,8 @@
 
 #include "lldb/Host/TaskPool.h"
 
+using namespace lldb_private;
+
 TEST(TaskPoolTest, AddTask) {
   auto fn = [](int x) { return x * x + 1; };
 
Index: lldb/trunk/source/Host/common/TaskPool.cpp
===
--- lldb/trunk/source/Host/common/TaskPool.cpp
+++ lldb/trunk/source/Host/common/TaskPool.cpp
@@ -14,6 +14,8 @@
 #include// for queue
 #include   // for thread
 
+namespace lldb_private {
+
 namespace {
 class TaskPoolImpl {
 public:
@@ -46,13 +48,20 @@
 
 TaskPoolImpl::TaskPoolImpl() : m_thread_count(0) {}
 
+unsigned GetHardwareConcurrencyHint() {
+  // std::thread::hardware_concurrency may return 0
+  // if the value is not well defined or not computable.
+  static const unsigned g_hardware_concurrency = 
+std::max(1u, std::thread::hardware_concurrency());
+  return g_hardware_concurrency;
+}
+
 void TaskPoolImpl::AddTask(std::function &&task_fn) {
-  static const uint32_t max_threads = std::thread::hardware_concurrency();
   const size_t min_stack_size = 8 * 1024 * 1024;
 
   std::unique_lock lock(m_tasks_mutex);
   m_tasks.emplace(std::move(task_fn));
-  if (m_thread_count < max_threads) {
+  if (m_thread_count < GetHardw

[Lldb-commits] [lldb] r319492 - [lldb] A few minor fixes in TaskPool

[Alexander Shaposhnikov via lldb-commits]

Author: alexshap
Date: Thu Nov 30 14:56:11 2017
New Revision: 319492

URL: http://llvm.org/viewvc/llvm-project?rev=319492&view=rev
Log:
[lldb] A few minor fixes in TaskPool

1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std::thread::hardware_concurrency may return 0,
handle this case correctly.

Differential revision: https://reviews.llvm.org/D40587

Test plan: make check-all

Modified:
lldb/trunk/include/lldb/Host/TaskPool.h
lldb/trunk/source/Host/common/TaskPool.cpp
lldb/trunk/unittests/Host/TaskPoolTest.cpp

Modified: lldb/trunk/include/lldb/Host/TaskPool.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/TaskPool.h?rev=319492&r1=319491&r2=319492&view=diff
==
--- lldb/trunk/include/lldb/Host/TaskPool.h (original)
+++ lldb/trunk/include/lldb/Host/TaskPool.h Thu Nov 30 14:56:11 2017
@@ -18,6 +18,8 @@
 #include// for mutex, unique_lock, condition_variable
 #include  // for forward, result_of, move
 
+namespace lldb_private {
+
 // Global TaskPool class for running tasks in parallel on a set of worker 
thread
 // created the first
 // time the task pool is used. The TaskPool provide no guarantee about the 
order
@@ -89,4 +91,8 @@ template <> struct TaskPool::RunTaskImpl
 void TaskMapOverInt(size_t begin, size_t end,
 const llvm::function_ref &func);
 
+unsigned GetHardwareConcurrencyHint();
+
+} // namespace lldb_private
+
 #endif // #ifndef utility_TaskPool_h_

Modified: lldb/trunk/source/Host/common/TaskPool.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/TaskPool.cpp?rev=319492&r1=319491&r2=319492&view=diff
==
--- lldb/trunk/source/Host/common/TaskPool.cpp (original)
+++ lldb/trunk/source/Host/common/TaskPool.cpp Thu Nov 30 14:56:11 2017
@@ -14,6 +14,8 @@
 #include// for queue
 #include   // for thread
 
+namespace lldb_private {
+
 namespace {
 class TaskPoolImpl {
 public:
@@ -46,13 +48,20 @@ void TaskPool::AddTaskImpl(std::function
 
 TaskPoolImpl::TaskPoolImpl() : m_thread_count(0) {}
 
+unsigned GetHardwareConcurrencyHint() {
+  // std::thread::hardware_concurrency may return 0
+  // if the value is not well defined or not computable.
+  static const unsigned g_hardware_concurrency = 
+std::max(1u, std::thread::hardware_concurrency());
+  return g_hardware_concurrency;
+}
+
 void TaskPoolImpl::AddTask(std::function &&task_fn) {
-  static const uint32_t max_threads = std::thread::hardware_concurrency();
   const size_t min_stack_size = 8 * 1024 * 1024;
 
   std::unique_lock lock(m_tasks_mutex);
   m_tasks.emplace(std::move(task_fn));
-  if (m_thread_count < max_threads) {
+  if (m_thread_count < GetHardwareConcurrencyHint()) {
 m_thread_count++;
 // Note that this detach call needs to happen with the m_tasks_mutex held.
 // This prevents the thread
@@ -77,7 +86,7 @@ void TaskPoolImpl::Worker(TaskPoolImpl *
   break;
 }
 
-std::function f = pool->m_tasks.front();
+std::function f = std::move(pool->m_tasks.front());
 pool->m_tasks.pop();
 lock.unlock();
 
@@ -87,10 +96,9 @@ void TaskPoolImpl::Worker(TaskPoolImpl *
 
 void TaskMapOverInt(size_t begin, size_t end,
 const llvm::function_ref &func) {
+  const size_t num_workers = std::min(end, 
GetHardwareConcurrencyHint());
   std::atomic idx{begin};
-  size_t num_workers =
-  std::min(end, std::thread::hardware_concurrency());
-
+  
   auto wrapper = [&idx, end, &func]() {
 while (true) {
   size_t i = idx.fetch_add(1);
@@ -107,3 +115,6 @@ void TaskMapOverInt(size_t begin, size_t
   for (size_t i = 0; i < num_workers; i++)
 futures[i].wait();
 }
+
+} // namespace lldb_private
+

Modified: lldb/trunk/unittests/Host/TaskPoolTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/TaskPoolTest.cpp?rev=319492&r1=319491&r2=319492&view=diff
==
--- lldb/trunk/unittests/Host/TaskPoolTest.cpp (original)
+++ lldb/trunk/unittests/Host/TaskPoolTest.cpp Thu Nov 30 14:56:11 2017
@@ -2,6 +2,8 @@
 
 #include "lldb/Host/TaskPool.h"
 
+using namespace lldb_private;
+
 TEST(TaskPoolTest, AddTask) {
   auto fn = [](int x) { return x * x + 1; };
 


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

[Lldb-commits] [lldb] r319500 - We had a situation where a kext was inlined into the kernel,

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Nov 30 15:31:18 2017
New Revision: 319500

URL: http://llvm.org/viewvc/llvm-project?rev=319500&view=rev
Log:
We had a situation where a kext was inlined into the kernel,
but still listed in the kernel's kext table with the kernel
binary UUID.  This resulted in the kernel text section being
loaded at the kext address and problems ensuing.  Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.

 

Modified:

lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp

Modified: 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=319500&r1=319499&r2=319500&view=diff
==
--- 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 Thu Nov 30 15:31:18 2017
@@ -1229,6 +1229,16 @@ bool DynamicLoaderDarwinKernel::ParseKex
 break;
   }
 }
+// If this "kext" entry is actually an alias for the kernel --
+// the kext was compiled into the kernel or something -- then
+// we don't want to load the kernel's text section at a different
+// address.  Ignore this kext entry.
+if (kext_summaries[new_kext].GetUUID().IsValid() 
+&& m_kernel.GetUUID().IsValid() 
+&& kext_summaries[new_kext].GetUUID() == m_kernel.GetUUID()) {
+  to_be_added[new_kext] = false;
+  break;
+}
 if (add_this_one) {
   number_of_new_kexts_being_added++;
 }


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

[Lldb-commits] [PATCH] D40636: Create a trivial lldb-test program

[Davide Italiano via Phabricator via lldb-commits]

davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

This LGTM. I think we can iterate in tree from what we have.


https://reviews.llvm.org/D40636



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

[Lldb-commits] [PATCH] D40636: Create a trivial lldb-test program

[Zachary Turner via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL319504: Add lldb-test. (authored by zturner).

Changed prior to commit:
  https://reviews.llvm.org/D40636?vs=124960&id=125052#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D40636

Files:
  lldb/trunk/tools/CMakeLists.txt
  lldb/trunk/tools/lldb-test/CMakeLists.txt
  lldb/trunk/tools/lldb-test/FormatUtil.cpp
  lldb/trunk/tools/lldb-test/FormatUtil.h
  lldb/trunk/tools/lldb-test/SystemInitializerTest.cpp
  lldb/trunk/tools/lldb-test/SystemInitializerTest.h
  lldb/trunk/tools/lldb-test/lldb-test.cpp

Index: lldb/trunk/tools/CMakeLists.txt
===
--- lldb/trunk/tools/CMakeLists.txt
+++ lldb/trunk/tools/CMakeLists.txt
@@ -9,3 +9,4 @@
   add_subdirectory(lldb-server)
 endif()
 add_subdirectory(intel-features)
+add_subdirectory(lldb-test)
Index: lldb/trunk/tools/lldb-test/SystemInitializerTest.cpp
===
--- lldb/trunk/tools/lldb-test/SystemInitializerTest.cpp
+++ lldb/trunk/tools/lldb-test/SystemInitializerTest.cpp
@@ -0,0 +1,345 @@
+//===-- SystemInitializerTest.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "SystemInitializerTest.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/Host.h"
+#include "lldb/Initialization/SystemInitializerCommon.h"
+#include "lldb/Interpreter/CommandInterpreter.h"
+#include "lldb/Symbol/ClangASTContext.h"
+#include "lldb/Symbol/GoASTContext.h"
+#include "lldb/Symbol/JavaASTContext.h"
+#include "lldb/Symbol/OCamlASTContext.h"
+#include "lldb/Utility/Timer.h"
+
+#include "Plugins/ABI/MacOSX-arm/ABIMacOSX_arm.h"
+#include "Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.h"
+#include "Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h"
+#include "Plugins/ABI/SysV-arm/ABISysV_arm.h"
+#include "Plugins/ABI/SysV-arm64/ABISysV_arm64.h"
+#include "Plugins/ABI/SysV-hexagon/ABISysV_hexagon.h"
+#include "Plugins/ABI/SysV-i386/ABISysV_i386.h"
+#include "Plugins/ABI/SysV-mips/ABISysV_mips.h"
+#include "Plugins/ABI/SysV-mips64/ABISysV_mips64.h"
+#include "Plugins/ABI/SysV-ppc/ABISysV_ppc.h"
+#include "Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h"
+#include "Plugins/ABI/SysV-s390x/ABISysV_s390x.h"
+#include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
+#include "Plugins/Architecture/Arm/ArchitectureArm.h"
+#include "Plugins/Disassembler/llvm/DisassemblerLLVMC.h"
+#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.h"
+#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
+#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
+#include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h"
+#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
+#include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h"
+#include "Plugins/InstrumentationRuntime/ASan/ASanRuntime.h"
+#include "Plugins/InstrumentationRuntime/MainThreadChecker/MainThreadCheckerRuntime.h"
+#include "Plugins/InstrumentationRuntime/TSan/TSanRuntime.h"
+#include "Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.h"
+#include "Plugins/JITLoader/GDB/JITLoaderGDB.h"
+#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
+#include "Plugins/Language/Go/GoLanguage.h"
+#include "Plugins/Language/Java/JavaLanguage.h"
+#include "Plugins/Language/OCaml/OCamlLanguage.h"
+#include "Plugins/Language/ObjC/ObjCLanguage.h"
+#include "Plugins/Language/ObjCPlusPlus/ObjCPlusPlusLanguage.h"
+#include "Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h"
+#include "Plugins/LanguageRuntime/Go/GoLanguageRuntime.h"
+#include "Plugins/LanguageRuntime/Java/JavaLanguageRuntime.h"
+#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h"
+#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h"
+#include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h"
+#include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h"
+#include "Plugins/OperatingSystem/Go/OperatingSystemGo.h"
+#include "Plugins/Platform/Android/PlatformAndroid.h"
+#include "Plugins/Platform/FreeBSD/PlatformFreeBSD.h"
+#include "Plugins/Platform/Kalimba/PlatformKalimba.h"
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteiOS.h"
+#include "Plugins/Platform/NetBSD/PlatformNetBSD.h"
+#include "Plugins/Platform/OpenBSD/PlatformOpenBSD.h"
+#include "Plugins/Platform/Windows/PlatformWindows.h"
+#include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
+#include "Plugins/Process/elf-core/ProcessElfCore.h"
+#include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
+#inclu

[Lldb-commits] [lldb] r319504 - Add lldb-test.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 30 16:52:51 2017
New Revision: 319504

URL: http://llvm.org/viewvc/llvm-project?rev=319504&view=rev
Log:
Add lldb-test.

This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB.  I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.

Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.

Run the tool as `lldb-test module-sections `.

Feel free to add testing related stuff to your heart's content after
this goes in.  Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.

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

Added:
lldb/trunk/tools/lldb-test/
lldb/trunk/tools/lldb-test/CMakeLists.txt
lldb/trunk/tools/lldb-test/FormatUtil.cpp
lldb/trunk/tools/lldb-test/FormatUtil.h
lldb/trunk/tools/lldb-test/SystemInitializerTest.cpp
lldb/trunk/tools/lldb-test/SystemInitializerTest.h
lldb/trunk/tools/lldb-test/lldb-test.cpp
Modified:
lldb/trunk/tools/CMakeLists.txt

Modified: lldb/trunk/tools/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/CMakeLists.txt?rev=319504&r1=319503&r2=319504&view=diff
==
--- lldb/trunk/tools/CMakeLists.txt (original)
+++ lldb/trunk/tools/CMakeLists.txt Thu Nov 30 16:52:51 2017
@@ -9,3 +9,4 @@ if (LLDB_CAN_USE_LLDB_SERVER)
   add_subdirectory(lldb-server)
 endif()
 add_subdirectory(intel-features)
+add_subdirectory(lldb-test)

Added: lldb/trunk/tools/lldb-test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-test/CMakeLists.txt?rev=319504&view=auto
==
--- lldb/trunk/tools/lldb-test/CMakeLists.txt (added)
+++ lldb/trunk/tools/lldb-test/CMakeLists.txt Thu Nov 30 16:52:51 2017
@@ -0,0 +1,27 @@
+get_property(LLDB_ALL_PLUGINS GLOBAL PROPERTY LLDB_PLUGINS)
+
+add_lldb_tool(lldb-test
+  FormatUtil.cpp
+  lldb-test.cpp
+  SystemInitializerTest.cpp
+
+  LINK_LIBS
+lldbBase
+lldbBreakpoint
+lldbCore
+lldbDataFormatters
+lldbExpression
+lldbHost
+lldbInitialization
+lldbInterpreter
+lldbSymbol
+lldbTarget
+lldbUtility
+${LLDB_ALL_PLUGINS}
+${host_lib}
+
+  LINK_COMPONENTS
+Support
+  )
+  
+include_directories(${LLDB_SOURCE_DIR}/source)

Added: lldb/trunk/tools/lldb-test/FormatUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-test/FormatUtil.cpp?rev=319504&view=auto
==
--- lldb/trunk/tools/lldb-test/FormatUtil.cpp (added)
+++ lldb/trunk/tools/lldb-test/FormatUtil.cpp Thu Nov 30 16:52:51 2017
@@ -0,0 +1,69 @@
+//===- FormatUtil.cpp - *- C++ 
--*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "FormatUtil.h"
+#include "llvm/Support/Format.h"
+#include "llvm/Support/FormatVariadic.h"
+
+using namespace lldb_private;
+using namespace llvm;
+
+LinePrinter::LinePrinter(int Indent, llvm::raw_ostream &Stream)
+: OS(Stream), IndentSpaces(Indent), CurrentIndent(0) {}
+
+void LinePrinter::Indent(uint32_t Amount) {
+  if (Amount == 0)
+Amount = IndentSpaces;
+  CurrentIndent += Amount;
+}
+
+void LinePrinter::Unindent(uint32_t Amount) {
+  if (Amount == 0)
+Amount = IndentSpaces;
+  CurrentIndent = std::max(0, CurrentIndent - Amount);
+}
+
+void LinePrinter::NewLine() {
+  OS << "\n";
+  OS.indent(CurrentIndent);
+}
+
+void LinePrinter::print(const Twine &T) { OS << T; }
+
+void LinePrinter::printLine(const Twine &T) {
+  NewLine();
+  OS << T;
+}
+
+void LinePrinter::formatBinary(StringRef Label, ArrayRef Data,
+   uint32_t StartOffset) {
+  NewLine();
+  OS << Label << " (";
+  if (!Data.empty()) {
+OS << "\n";
+OS << format_bytes_with_ascii(Data, StartOffset, 32, 4,
+  CurrentIndent + IndentSpaces, true);
+NewLine();
+  }
+  OS << ")";
+}
+
+void LinePrinter::formatBinary(StringRef Label, ArrayRef Data,
+   uint64_t Base, uint32_t StartOffset) {
+  NewLine();
+  OS << Label << " (";
+  if (!Data.empty()) {
+OS << "\n";
+Base += StartOffset;
+OS << format_bytes_with_ascii(Data, Base, 32, 4,
+  CurrentIndent + IndentSpaces, true);
+NewLine();
+  }
+  OS << ")";
+}

Added: lldb/trunk/tools/lldb-t

[Lldb-commits] [lldb] r319516 - ClangASTContext::ParseClassTemplateDecl doesn't always succeed.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Nov 30 19:41:30 2017
New Revision: 319516

URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev
Log:
ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
When it does, it returns a NULL ClassTemplateDecl.  Don't use 
it if it is NULL...



Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=319516&r1=319515&r2=319516&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Thu Nov 
30 19:41:30 2017
@@ -786,7 +786,17 @@ TypeSP DWARFASTParserClang::ParseTypeFro
   m_ast.ParseClassTemplateDecl(decl_ctx, accessibility,
type_name_cstr, tag_decl_kind,
template_param_infos);
-
+  if (!class_template_decl) {
+if (log) {
+  dwarf->GetObjectFile()->GetModule()->LogMessage(
+log, "SymbolFileDWARF(%p) - 0x%8.8x: %s type \"%s\" "
+ "clang::ClassTemplateDecl failed to return a decl.",
+static_cast(this), die.GetOffset(),
+DW_TAG_value_to_name(tag), type_name_cstr);
+}
+return TypeSP();
+  }
+
   clang::ClassTemplateSpecializationDecl
   *class_specialization_decl =
   m_ast.CreateClassTemplateSpecializationDecl(


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

Re: [Lldb-commits] [lldb] r319516 - ClangASTContext::ParseClassTemplateDecl doesn't always succeed.

[Davide Italiano via lldb-commits]

On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits
 wrote:
> Author: jingham
> Date: Thu Nov 30 19:41:30 2017
> New Revision: 319516
>
> URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev
> Log:
> ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
> When it does, it returns a NULL ClassTemplateDecl.  Don't use
> it if it is NULL...
>
> 
>

Is there a way to test this? There should be one.
Not an expert in the ASTContext, so please feel free to correct me if I'm wrong.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits