date:20190802

[Lldb-commits] [PATCH] D63165: Initial support for native debugging of x86/x64 Windows processes

2019-08-02 Thread Aaron Smith via Phabricator via lldb-commits

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



Comment at: 
lldb/source/Plugins/Process/Utility/RegisterContextWindows_x86_64.cpp:141
+GetRegisterInfo_WoW64(const lldb_private::ArchSpec &arch) {
+  // A WoW64 register info is the same as the i386's.
+  std::vector &g_register_infos =

labath wrote:
> labath wrote:
> > asmith wrote:
> > > labath wrote:
> > > > Hui wrote:
> > > > > labath wrote:
> > > > > > Why is all of this complexity necessary? Couldn't you just switch 
> > > > > > on the target architecture in `CreateRegisterInfoInterface` in 
> > > > > > NativeRegisterContextWindows_x86_64.cpp and create either 
> > > > > > `RegisterContextWindows_WoW64` or `RegisterContextWindows_x86_64` ?
> > > > > > 
> > > > > > In fact, if RegisterContextWindows_WoW64 is identical to 
> > > > > > RegisterContextWindows_i386, then why do you even need the _WoW64 
> > > > > > version of the class in the first place? FWIW, linux also does not 
> > > > > > have a RegisterContextLinux_32_bit_process_on_64_bit_kernel class...
> > > > > I think WoW64 is i686 that shall deserve a separate arch specific 
> > > > > implementation?
> > > > I am sorry, but I don't follow. Can you repeat the question?
> > > > 
> > > > (FWIW, I don't believe that the fact that two things are different from 
> > > > a certain point of view justifies copy-pasting (at least) 150 LOC. If 
> > > > you think it's confusing to use something called "i386" in things 
> > > > dealing with WoW64, you can always typedef the WOW64 context to it, or 
> > > > rename the i386 context to something more generic.)
> > > I don't want this to block the review and have removed the code.
> > Thanks. FTR, I'm not opposed to splitting these classes again in the 
> > future, if we develop a need for them to diverge (though it would be nice 
> > to find a way to factor the common parts in that case).
> > 
> > However, there's one more thing that bothers me here. It's this business 
> > with constructing a `RegisterContextWindows_i386` here, copying the entries 
> > out of it, and re-using them elsewhere while asserting that things were 
> > done in the right order. It seems very complex, and I'm not sure that 
> > complexity is needed. It seems to me like all of that could be removed if 
> > you just made the decision which set of registers to use one level up 
> > (i.e., in `CreateRegisterInfoInterface` in 
> > NativeRegisterContextWindows_x86_64.cpp. You could just have that function 
> > switch on the process byte size, and return RegisterContextWindows_i386 or 
> > RegisterContextWindows_x86_64. This is the same way things are done on x86 
> > linux (see NativeRegisterContextLinux_x86_64.cpp).
> Unfortunately NativeRegisterContextLinux_x86_64 is not good example here. It 
> turns I misread, and that class actually switches on the *host* architecture 
> instead of *target*, and its implementation of RegisterContextLinux_x86_64 
> does indeed the i386 copying tricks that are very similar to what you do 
> here. However, that class has the "excuse" of needing to fix up the register 
> offsets in the i386-on-x86_64 case (for those following along: see 
> `UPDATE_REGISTER_INFOS_I386_STRUCT_WITH_X86_64_OFFSETS`). You don't need to 
> do anything like that here, so I would hope that we can do something simpler 
> here.
> 
> And I'll try to figure out a way to do the linux thing in a saner fashion... 
Are you accepting this review? 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63165/new/

https://reviews.llvm.org/D63165



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

[Lldb-commits] [PATCH] D63165: Initial support for native debugging of x86/x64 Windows processes

2019-08-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

> Are you accepting this review?

No I would still like to see the two comments I made in https://reviews.llvm.org/D63165#1607877>> to be addressed. The last comment 
was just acknowledging the fact that you (or is it @Hui? I'm not sure who 
actually writes these patches...) were following the existing pattern in the 
linux register contexts. However, the pattern over there is for a reason, and 
that reason does not apply here. That doesn't make the linux code less ugly 
(probably the opposite), but it does mean we shouldn't try to emulate it if 
there are better options available...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63165/new/

https://reviews.llvm.org/D63165



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

[Lldb-commits] [PATCH] D65414: Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

2019-08-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D65414#1610923 , @shafik wrote:

> @labath @stella.stamenova I updated the diff with a fix that I believe should 
> address the test failure.
>
> This is an unfortunate difference in how DWARF and PDB works. After spending 
> some time digging into this I don't see the key difference that allows DWARF 
> to work w/o `addDecl`. I believe further work along the lines of D55571 
>  may help but my first attempts at fixing 
> this for DWARF were not successful.


@stella.stamenova, was the comment in https://reviews.llvm.org/D55571#1611200>> meant for this patch?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65414/new/

https://reviews.llvm.org/D65414



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

[Lldb-commits] [lldb] r367664 - SymbolVendor: Introduce Module::GetSymbolFile

2019-08-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Fri Aug  2 01:16:35 2019
New Revision: 367664

URL: http://llvm.org/viewvc/llvm-project?rev=367664&view=rev
Log:
SymbolVendor: Introduce Module::GetSymbolFile

Summary:
This is the next step in avoiding funneling all SymbolFile calls through
the SymbolVendor. Right now, it is just a convenience function, but it
allows us to update all calls to SymbolVendor functions to access the
SymbolFile directly. Once all call sites have been updated, we can
remove the GetSymbolVendor member function.

This patch just updates the calls to GetSymbolVendor, which were calling
it just so they could fetch the underlying symbol file. Other calls will
be done in follow-ups.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

Modified:
lldb/trunk/include/lldb/Core/Module.h
lldb/trunk/source/Commands/CommandObjectTarget.cpp
lldb/trunk/source/Core/Module.cpp
lldb/trunk/source/Expression/IRExecutionUnit.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Symbol/Block.cpp
lldb/trunk/source/Symbol/Function.cpp
lldb/trunk/source/Symbol/UnwindTable.cpp

Modified: lldb/trunk/include/lldb/Core/Module.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Module.h?rev=367664&r1=367663&r2=367664&view=diff
==
--- lldb/trunk/include/lldb/Core/Module.h (original)
+++ lldb/trunk/include/lldb/Core/Module.h Fri Aug  2 01:16:35 2019
@@ -653,6 +653,9 @@ public:
   GetSymbolVendor(bool can_create = true,
   lldb_private::Stream *feedback_strm = nullptr);
 
+  SymbolFile *GetSymbolFile(bool can_create = true,
+Stream *feedback_strm = nullptr);
+
   /// Get a reference to the UUID value contained in this object.
   ///
   /// If the executable image file doesn't not have a UUID value built into

Modified: lldb/trunk/source/Commands/CommandObjectTarget.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectTarget.cpp?rev=367664&r1=367663&r2=367664&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp Fri Aug  2 01:16:35 2019
@@ -2259,8 +2259,8 @@ protected:
 if (m_interpreter.WasInterrupted())
   break;
 Module *m = target->GetImages().GetModulePointerAtIndex(image_idx);
-SymbolFile *sf = m->GetSymbolVendor()->GetSymbolFile();
-sf->DumpClangAST(result.GetOutputStream());
+if (SymbolFile *sf = m->GetSymbolFile())
+  sf->DumpClangAST(result.GetOutputStream());
   }
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
@@ -2285,8 +2285,8 @@ protected:
 if (m_interpreter.WasInterrupted())
   break;
 Module *m = module_list.GetModulePointerAtIndex(i);
-SymbolFile *sf = m->GetSymbolVendor()->GetSymbolFile();
-sf->DumpClangAST(result.GetOutputStream());
+if (SymbolFile *sf = m->GetSymbolFile())
+  sf->DumpClangAST(result.GetOutputStream());
   }
 }
 result.SetStatus(eReturnStatusSuccessFinishResult);
@@ -3272,9 +3272,9 @@ protected:
 
   case 's':
   case 'S': {
-const SymbolVendor *symbol_vendor = module->GetSymbolVendor();
-if (symbol_vendor) {
-  const FileSpec symfile_spec = symbol_vendor->GetMainFileSpec();
+if (const SymbolFile *symbol_file = module->GetSymbolFile()) {
+  const FileSpec symfile_spec =
+  symbol_file->GetObjectFile()->GetFileSpec();
   if (format_char == 'S') {
 // Dump symbol file only if different from module file
 if (!symfile_spec || symfile_spec == module->GetFileSpec()) {
@@ -4207,48 +4207,44 @@ protected:
 // decides to create it!
 module_sp->SetSymbolFileFileSpec(symbol_fspec);
 
-SymbolVendor *symbol_vendor =
-module_sp->GetSymbolVendor(true, &result.GetErrorStream());
-if (symbol_vendor) {
-  SymbolFile *symbol_file = symbol_vendor->GetSymbolFile();
-
-  if (symbol_file) {
-ObjectFile *object_file = symbol_file->GetObjectFile();
-
-if (object_file && object_file->GetFileSpec() == symbol_fspec) {
-  // Provide feedback that the symfile has been successfully added.
-  const FileSpec &module_fs = module_sp->GetFileSpec();
-  result.AppendMessageWithFormat(
-  "symbol file '%s' has been added to '%s'\n", symfile_path,
-  module_fs.GetPath().c_str());
-
-  // Let clients know something changed in the module if it is
-  // currently loaded
-  ModuleList module_lis

[Lldb-commits] [PATCH] D65435: SymbolVendor: Introduce Module::GetSymbolFile

2019-08-02 Thread Pavel Labath via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367664: SymbolVendor: Introduce Module::GetSymbolFile 
(authored by labath, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65435/new/

https://reviews.llvm.org/D65435

Files:
  lldb/trunk/include/lldb/Core/Module.h
  lldb/trunk/source/Commands/CommandObjectTarget.cpp
  lldb/trunk/source/Core/Module.cpp
  lldb/trunk/source/Expression/IRExecutionUnit.cpp
  lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/trunk/source/Symbol/Block.cpp
  lldb/trunk/source/Symbol/Function.cpp
  lldb/trunk/source/Symbol/UnwindTable.cpp

Index: lldb/trunk/include/lldb/Core/Module.h
===
--- lldb/trunk/include/lldb/Core/Module.h
+++ lldb/trunk/include/lldb/Core/Module.h
@@ -653,6 +653,9 @@
   GetSymbolVendor(bool can_create = true,
   lldb_private::Stream *feedback_strm = nullptr);
 
+  SymbolFile *GetSymbolFile(bool can_create = true,
+Stream *feedback_strm = nullptr);
+
   /// Get a reference to the UUID value contained in this object.
   ///
   /// If the executable image file doesn't not have a UUID value built into
Index: lldb/trunk/source/Core/Module.cpp
===
--- lldb/trunk/source/Core/Module.cpp
+++ lldb/trunk/source/Core/Module.cpp
@@ -366,7 +366,7 @@
 
   SymbolContext sc;
   sc.module_sp = shared_from_this();
-  SymbolVendor *symbols = GetSymbolVendor();
+  SymbolFile *symbols = GetSymbolFile();
 
   for (size_t cu_idx = 0; cu_idx < num_comp_units; cu_idx++) {
 sc.comp_unit = symbols->GetCompileUnitAtIndex(cu_idx).get();
@@ -406,8 +406,7 @@
   static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
   Timer scoped_timer(func_cat, "Module::GetNumCompileUnits (module = %p)",
  static_cast(this));
-  SymbolVendor *symbols = GetSymbolVendor();
-  if (symbols)
+  if (SymbolFile *symbols = GetSymbolFile())
 return symbols->GetNumCompileUnits();
   return 0;
 }
@@ -418,8 +417,7 @@
   CompUnitSP cu_sp;
 
   if (index < num_comp_units) {
-SymbolVendor *symbols = GetSymbolVendor();
-if (symbols)
+if (SymbolFile *symbols = GetSymbolFile())
   cu_sp = symbols->GetCompileUnitAtIndex(index);
   }
   return cu_sp;
@@ -457,8 +455,8 @@
 sc.module_sp = shared_from_this();
 resolved_flags |= eSymbolContextModule;
 
-SymbolVendor *sym_vendor = GetSymbolVendor();
-if (!sym_vendor)
+SymbolFile *symfile = GetSymbolFile();
+if (!symfile)
   return resolved_flags;
 
 // Resolve the compile unit, function, block, line table or line entry if
@@ -469,14 +467,14 @@
 resolve_scope & eSymbolContextLineEntry ||
 resolve_scope & eSymbolContextVariable) {
   resolved_flags |=
-  sym_vendor->ResolveSymbolContext(so_addr, resolve_scope, sc);
+  symfile->ResolveSymbolContext(so_addr, resolve_scope, sc);
 }
 
 // Resolve the symbol if requested, but don't re-look it up if we've
 // already found it.
 if (resolve_scope & eSymbolContextSymbol &&
 !(resolved_flags & eSymbolContextSymbol)) {
-  Symtab *symtab = sym_vendor->GetSymtab();
+  Symtab *symtab = symfile->GetSymtab();
   if (symtab && so_addr.IsSectionOffset()) {
 Symbol *matching_symbol = nullptr;
 
@@ -509,18 +507,15 @@
 // files on MacOSX have an unstripped symbol table inside of them.
 ObjectFile *symtab_objfile = symtab->GetObjectFile();
 if (symtab_objfile && symtab_objfile->IsStripped()) {
-  SymbolFile *symfile = sym_vendor->GetSymbolFile();
-  if (symfile) {
-ObjectFile *symfile_objfile = symfile->GetObjectFile();
-if (symfile_objfile != symtab_objfile) {
-  Symtab *symfile_symtab = symfile_objfile->GetSymtab();
-  if (symfile_symtab) {
-Symbol *symbol =
-symfile_symtab->FindSymbolContainingFileAddress(
-so_addr.GetFileAddress());
-if (symbol && !symbol->IsSynthetic()) {
-  sc.symbol = symbol;
-}
+  ObjectFile *symfile_objfile = symfile->GetObjectFile();
+  if (symfile_objfile != symtab_objfile) {
+Symtab *symfile_symtab = symfile_objfile->GetSymtab();
+if (symfile_symtab) {
+  Symbol *symbol =
+  symfile_symtab->FindSymbolContainingFileAddress(
+  so_addr.GetFileAddress());
+  if (symbol && !symbol->IsSynthetic()) {
+sc.symbol = symbol;
   }
 }

[Lldb-commits] [PATCH] D65640: Update LLDB to follow changes in llvm::DWARFDebugNames::NameIndex (4/5)

2019-08-02 Thread Igor Kudrin via Phabricator via lldb-commits

ikudrin created this revision.
ikudrin added reviewers: dblaikie, probinson, aprantl, clayborg, labath.
ikudrin added a project: LLDB.
Herald added a subscriber: arphaman.
ikudrin added a parent revision: D65638: Switch LLVM to use 64-bit offsets 
(2/5).

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65640

Files:
  source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp


Index: source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
===
--- source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -105,7 +105,7 @@
   if (!regex.Execute(nte.getString()))
 continue;
 
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 if (entry_or->tag() != DW_TAG_variable)
@@ -125,7 +125,7 @@
   uint64_t cu_offset = cu.GetOffset();
   for (const DebugNames::NameIndex &ni: *m_debug_names_up) {
 for (DebugNames::NameTableEntry nte: ni) {
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 if (entry_or->tag() != DW_TAG_variable)
@@ -248,7 +248,7 @@
   if (!regex.Execute(nte.getString()))
 continue;
 
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 Tag tag = entry_or->tag();


Index: source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
===
--- source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
+++ source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
@@ -105,7 +105,7 @@
   if (!regex.Execute(nte.getString()))
 continue;
 
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 if (entry_or->tag() != DW_TAG_variable)
@@ -125,7 +125,7 @@
   uint64_t cu_offset = cu.GetOffset();
   for (const DebugNames::NameIndex &ni: *m_debug_names_up) {
 for (DebugNames::NameTableEntry nte: ni) {
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 if (entry_or->tag() != DW_TAG_variable)
@@ -248,7 +248,7 @@
   if (!regex.Execute(nte.getString()))
 continue;
 
-  uint32_t entry_offset = nte.getEntryOffset();
+  uint64_t entry_offset = nte.getEntryOffset();
   llvm::Expected entry_or = ni.getEntry(&entry_offset);
   for (; entry_or; entry_or = ni.getEntry(&entry_offset)) {
 Tag tag = entry_or->tag();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D63165: Initial support for native debugging of x86/x64 Windows processes

2019-08-02 Thread Aaron Smith via Phabricator via lldb-commits

asmith added a comment.

I can make the one simplification but Im not sure what you are asking as far as 
the refactoring. Provide an example and I will try to accommodate your request. 
I'm not going to be able to spend much more time on lldb patches though.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63165/new/

https://reviews.llvm.org/D63165



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

[Lldb-commits] [PATCH] D63165: Initial support for native debugging of x86/x64 Windows processes

2019-08-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D63165#1611924 , @asmith wrote:

> I can make the one simplification but Im not sure what you are asking as far 
> as the refactoring. Provide an example and I will try to accommodate your 
> request. I'm not going to be able to spend much more time on lldb patches 
> though.

I think you should change the `CreateRegisterInfoInterface` in 
`NativeRegisterContextWindows_x86_64.cpp` to something like:

  static RegisterInfoInterface *
  CreateRegisterInfoInterface(const ArchSpec &target_arch) {
assert((HostInfo::GetArchitecture().GetAddressByteSize() == 8) &&
   "Register setting path assumes this is a 64-bit host");
switch (target.arch.GetAddressByteSize()) {
case 8:
  return new RegisterContextWindows_x86_64(target_arch);
case 8:
  return new RegisterContextWindows_i386(target_arch);
default:
  llvm_unreachable("Unsupported byte size!");
  }

Then you should be able to remove all of the `g_private_reg_interface` business 
from `RegisterContextWindows_x86_64.cpp`, as the RegisterContextWindows_x86_64 
will only ever be called with a 64-bit ArchSpec. In fact, since you already 
have NativeRegisterContextWindows_WoW64, I am not sure if even the `4` branch 
is needed, as in case of GetAddressByteSize() == 4, we should end up in 
`CreateRegisterInfoInterface` in `NativeRegisterContextWindows_WoW64` (which 
already correctly constructs a `RegisterContextWindows_i386`).

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63165/new/

https://reviews.llvm.org/D63165

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

[Lldb-commits] [PATCH] D65571: [lldb][NFC] Remove unused imports from Python tests

2019-08-02 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor closed this revision.
teemperor added a comment.

This has landed in sv as 367663 but it seems Phabricator struggles with this 
huge patch (as did git-llvm...).


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65571/new/

https://reviews.llvm.org/D65571



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

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions.

2019-08-02 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor created this revision.
teemperor added a reviewer: LLDB.
Herald added subscribers: lldb-commits, kadircet, arphaman, aprantl.
Herald added a project: LLDB.

Currently our expression evaluators only prints very basic errors that are not 
very useful when writing complex expressions.

For example, in the expression below the user made a type error, but it's not 
clear from the diagnostic what went wrong:

  (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
  error: invalid operands to binary expression ('int' and 'double')

This patch enables full Clang diagnostics in our expression evaluator. After 
this patch the diagnostics for the expression look like this:

  (lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
  error: :1:54: invalid operands to binary expression ('int' 
and 'float')
  printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
 ~~^~~~

To make this possible, we now emulate a user expression file within our 
diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.

Note that the diagnostics that refer to declarations from the debug information 
(e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated 
with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as 
they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should 
be enough to explain the issue).

Fixes rdar://24306342


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65646

Files:
  clang/include/clang/Basic/DiagnosticOptions.def
  clang/lib/Frontend/TextDiagnostic.cpp
  lldb/packages/Python/lldbsuite/test/expression_command/diagnostics/Makefile
  
lldb/packages/Python/lldbsuite/test/expression_command/diagnostics/TestExprDiagnostics.py
  lldb/packages/Python/lldbsuite/test/expression_command/diagnostics/main.cpp
  lldb/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods.py
  lldb/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
@@ -29,7 +29,9 @@
 
 using namespace lldb_private;
 
-const char *ClangExpressionSourceCode::g_expression_prefix = R"(
+const char *ClangExpressionSourceCode::g_expression_prefix =
+R"(
+#line 1 ""
 #ifndef offsetof
 #define offsetof(t, d) __builtin_offsetof(t, d)
 #endif
@@ -67,8 +69,8 @@
 }
 )";
 
-static const char *c_start_marker = "/*LLDB_BODY_START*/\n";
-static const char *c_end_marker = ";\n/*LLDB_BODY_END*/\n";
+static const char *c_start_marker = "#line 1 \"\"\n";
+static const char *c_end_marker = "\n;/*LLDB_BODY_END*/\n";
 
 namespace {
 
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -137,12 +137,14 @@
 
 class ClangDiagnosticManagerAdapter : public clang::DiagnosticConsumer {
 public:
-  ClangDiagnosticManagerAdapter()
-  : m_passthrough(new clang::TextDiagnosticBuffer) {}
-
-  ClangDiagnosticManagerAdapter(
-  const std::shared_ptr &passthrough)
-  : m_passthrough(passthrough) {}
+  ClangDiagnosticManagerAdapter(DiagnosticOptions &opts) {
+DiagnosticOptions *m_options = new DiagnosticOptions(opts);
+m_options->ShowPresumedLoc = true;
+m_options->ShowLevel = false;
+m_os.reset(new llvm::raw_string_ostream(m_output));
+m_passthrough.reset(
+new clang::TextDiagnosticPrinter(*m_os, m_options, false));
+  }
 
   void ResetManager(DiagnosticManager *manager = nullptr) {
 m_manager = manager;
@@ -150,12 +152,11 @@
 
   void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
 const clang::Diagnostic &Info) override {
-if (m_manager) {
-  llvm::SmallVector diag_str;
-  Info.FormatDiagnostic(diag_str);
-  diag_str.push_back('\0');
-  const char *data = diag_str.data();
+m_output.clear();
+m_passthrough->HandleDiagnostic(DiagLevel, Info);
+m_os->flush();
 
+if (m_manager) {
   lldb_private::DiagnosticSeverity severity;
   bool make_new_diagnostic = true;
 
@@ -172,12 +173,16 @@
 severity = eDiagnosticSeverityRemark;
 break;
   case DiagnosticsEngine::Level::Note:
-m_manager->AppendMessageT

[Lldb-commits] [PATCH] D65566: [lldb][CMake] Workaround debugserver code-signing issue in generated Xcode project

2019-08-02 Thread Stefan Gränitz via Phabricator via lldb-commits

sgraenitz added a comment.

In D65566#1611007 , @JDevlieghere 
wrote:

> Is there a way to use the debugserver in the framework instead?

This patch is about the debugserver in the framework. It must be signed, 
because the lldb driver uses it implicitly and, apparently, that is the correct 
behavior.
debugserver is built as `bin/debugserver` and copied to 
`bin/LLDB.framework/Resources/debugserver` (the latter is currently not signed 
in Xcode builds).

> This seems like the inverse of the problem we had earlier with the RPATHs, 
> where we would fix them up in the build tree after copying them.

It's purely about the functionality of the build-tree lldb.

BTW The problem you may refer to (--> 
https://reviews.llvm.org/D61952#change-2C1slKxbErMH ?) is unrelated, but it's 
still existing when installing with the framework. Currently it doesn't show up 
upstream, because in practice configuration-order defines install-order. So, we 
are good as long as tools that go into the framework are configured after the 
framework.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65566/new/

https://reviews.llvm.org/D65566

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

[Lldb-commits] [PATCH] D65647: Fix line table resolution near the end of a section

2019-08-02 Thread Pavel Labath via Phabricator via lldb-commits

labath created this revision.
labath added reviewers: clayborg, jingham.
Herald added a subscriber: mgorny.

lld r367537 changed the way the linker organizes sections and segments.
This exposed an lldb bug and caused some tests to fail.

In all of the failing tests the root cause was the same -- when we were
trying to resolve the last address in the line_table section, we failed
because it pointed past the end of the section.

This is similar to the problem encountered in D32022 
, where we had a
problem with unwinding of functions near the end of the section/module.
In that patch, we added a flag which allowed these end addresses to
resolve to the section, but we only did so for load address computations
(SectionLoadList). line table uses file addresses, and so we are not
able to take advantage of that here.

This patch adds an equivalent flag to the SectionList class, and changes
the line table resolving code to use it for end-of-sequence entries (as
those are the only ones that can validly point outside of a section).

I also revert the linker flags which were added to the failing tests to
restore previous behavior, and add a unit test to exercise the new API
more directly.


https://reviews.llvm.org/D65647

Files:
  include/lldb/Core/Module.h
  include/lldb/Core/Section.h
  lit/SymbolFile/DWARF/debug-line-basic.s
  lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s
  lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s
  lit/SymbolFile/DWARF/dir-separator-posix.s
  lit/SymbolFile/DWARF/dir-separator-windows.s
  source/Core/Module.cpp
  source/Core/Section.cpp
  source/Symbol/LineTable.cpp
  unittests/Core/CMakeLists.txt
  unittests/Core/Inputs/resolve-file-address.yaml
  unittests/Core/ModuleTest.cpp

Index: unittests/Core/ModuleTest.cpp
===
--- /dev/null
+++ unittests/Core/ModuleTest.cpp
@@ -0,0 +1,69 @@
+//===-- ModuleTest.cpp --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Core/Module.h"
+#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
+#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
+#include "TestingSupport/TestUtilities.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/HostInfo.h"
+#include "llvm/Support/FileUtilities.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb;
+
+namespace {
+class ModuleTest : public testing::Test {
+public:
+  static void SetUpTestCase() {
+FileSystem::Initialize();
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
+SymbolFileSymtab::Initialize();
+  }
+
+  static void TearDownTestCase() {
+SymbolFileSymtab::Terminate();
+ObjectFileELF::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+  }
+};
+} // namespace
+
+llvm::Optional resolveFileAddress(Module &M, addr_t FileAddr,
+   bool AllowSectionEnd) {
+  Address A;
+  if (M.ResolveFileAddress(FileAddr, A, AllowSectionEnd))
+return A;
+  return llvm::None;
+}
+
+TEST_F(ModuleTest, ResolveFileAddress) {
+  llvm::SmallString<128> Obj;
+  ASSERT_EQ(llvm::sys::fs::createTemporaryFile("resolve-file-address-%%",
+   "obj", Obj),
+std::error_code());
+  llvm::FileRemover Deleter(Obj);
+  ASSERT_THAT_ERROR(ReadYAMLObjectFile("resolve-file-address.yaml", Obj),
+llvm::Succeeded());
+
+  ModuleSpec Spec{FileSpec(Obj)};
+  Spec.GetSymbolFileSpec().SetFile(Obj, FileSpec::Style::native);
+  auto M = std::make_shared(Spec);
+
+  ASSERT_TRUE(M->GetSectionList());
+  SectionSP S = M->GetSectionList()->FindSectionByName(ConstString(".text"));
+  ASSERT_TRUE(S);
+
+  EXPECT_EQ(resolveFileAddress(*M, 0x1000, false), Address(S, 0));
+  EXPECT_EQ(resolveFileAddress(*M, 0x1100, false), llvm::None);
+  EXPECT_EQ(resolveFileAddress(*M, 0x1100, true), Address(S, 0x100));
+}
Index: unittests/Core/Inputs/resolve-file-address.yaml
===
--- /dev/null
+++ unittests/Core/Inputs/resolve-file-address.yaml
@@ -0,0 +1,12 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_X86_64
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x1000
+Size:0x100
Index: unittests/Core/CMakeLists.txt
===
--- unittests/Core/CMakeLists.txt
+++ unittests/Core/CMa

[Lldb-commits] [PATCH] D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP]

2019-08-02 Thread Michał Górny via Phabricator via lldb-commits

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



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:737
+  for (auto it = m_threads.begin(); it != m_threads.end(); ++it) {
+if (*it && ((*it)->GetID() == thread_id)) {
+  m_threads.erase(it);

labath wrote:
> It looks like the rest of the code assumes (as I think it should) that the 
> thread list does not contain null pointers. See e.g. the loop on line 276.
For the record, I've copied it from Linux ;-P.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6/new/

https://reviews.llvm.org/D6



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

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions.

2019-08-02 Thread Adrian Prantl via Phabricator via lldb-commits

aprantl added a comment.

I have a question based on my half-knowledge about the expression evaluator: I 
thought that we already wrote out a temporary file for the expression in order 
to support `expr -g`? Is this orthogonal or do we now have to ways of 
pretending there is a source file backing up the expression?




Comment at: 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp:73
+static const char *c_start_marker = "#line 1 \"\"\n";
+static const char *c_end_marker = "\n;/*LLDB_BODY_END*/\n";
 

The comment seems asymmetric now.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65646/new/

https://reviews.llvm.org/D65646



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

[Lldb-commits] [PATCH] D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP]

2019-08-02 Thread JF Bastien via Phabricator via lldb-commits

jfb requested changes to this revision.
jfb added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:737
+  for (auto it = m_threads.begin(); it != m_threads.end(); ++it) {
+if (*it && ((*it)->GetID() == thread_id)) {
+  m_threads.erase(it);

mgorny wrote:
> labath wrote:
> > It looks like the rest of the code assumes (as I think it should) that the 
> > thread list does not contain null pointers. See e.g. the loop on line 276.
> For the record, I've copied it from Linux ;-P.
Are you serious? Because you absolutely cannot copy code from Linux into LLVM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6/new/

https://reviews.llvm.org/D6



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

[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Joseph Tremoulet via Phabricator via lldb-commits

JosephTremoulet updated this revision to Diff 213067.
JosephTremoulet added a comment.

- Expand comment about return trampolines
- rename PropagateTrapHandlerFlag -> PropagateTrapHandlerFlagFromUnwindPlan


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64993/new/

https://reviews.llvm.org/D64993

Files:
  lldb/include/lldb/Core/Address.h
  lldb/include/lldb/Target/StackFrame.h
  lldb/include/lldb/Target/Unwind.h
  lldb/lit/Unwind/Inputs/trap_frame_sym_ctx.s
  lldb/lit/Unwind/trap_frame_sym_ctx.test
  lldb/source/Core/Address.cpp
  lldb/source/Plugins/Process/Utility/HistoryUnwind.cpp
  lldb/source/Plugins/Process/Utility/HistoryUnwind.h
  lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
  lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp
  lldb/source/Plugins/Process/Utility/UnwindLLDB.h
  lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
  lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.h
  lldb/source/Target/StackFrame.cpp
  lldb/source/Target/StackFrameList.cpp

Index: lldb/source/Target/StackFrameList.cpp
===
--- lldb/source/Target/StackFrameList.cpp
+++ lldb/source/Target/StackFrameList.cpp
@@ -394,11 +394,13 @@
 bool cfa_is_valid = false;
 addr_t pc =
 callee->GetAddressRange().GetBaseAddress().GetLoadAddress(&target);
+constexpr bool behaves_like_zeroth_frame = false;
 SymbolContext sc;
 callee->CalculateSymbolContext(&sc);
 auto synth_frame = std::make_shared(
 m_thread.shared_from_this(), frame_idx, concrete_frame_idx, cfa,
-cfa_is_valid, pc, StackFrame::Kind::Artificial, &sc);
+cfa_is_valid, pc, StackFrame::Kind::Artificial,
+behaves_like_zeroth_frame, &sc);
 m_frames.push_back(synth_frame);
 LLDB_LOG(log, "Pushed frame {0}", callee->GetDisplayName());
   }
@@ -448,6 +450,7 @@
 uint32_t idx = m_concrete_frames_fetched++;
 lldb::addr_t pc = LLDB_INVALID_ADDRESS;
 lldb::addr_t cfa = LLDB_INVALID_ADDRESS;
+bool behaves_like_zeroth_frame = (idx == 0);
 if (idx == 0) {
   // We might have already created frame zero, only create it if we need
   // to.
@@ -455,8 +458,9 @@
 RegisterContextSP reg_ctx_sp(m_thread.GetRegisterContext());
 
 if (reg_ctx_sp) {
-  const bool success =
-  unwinder && unwinder->GetFrameInfoAtIndex(idx, cfa, pc);
+  const bool success = unwinder &&
+   unwinder->GetFrameInfoAtIndex(
+   idx, cfa, pc, behaves_like_zeroth_frame);
   // There shouldn't be any way not to get the frame info for frame
   // 0. But if the unwinder can't make one, lets make one by hand
   // with the SP as the CFA and see if that gets any further.
@@ -467,7 +471,7 @@
 
   unwind_frame_sp = std::make_shared(
   m_thread.shared_from_this(), m_frames.size(), idx, reg_ctx_sp,
-  cfa, pc, nullptr);
+  cfa, pc, behaves_like_zeroth_frame, nullptr);
   m_frames.push_back(unwind_frame_sp);
 }
   } else {
@@ -475,8 +479,9 @@
 cfa = unwind_frame_sp->m_id.GetCallFrameAddress();
   }
 } else {
-  const bool success =
-  unwinder && unwinder->GetFrameInfoAtIndex(idx, cfa, pc);
+  const bool success = unwinder &&
+   unwinder->GetFrameInfoAtIndex(
+   idx, cfa, pc, behaves_like_zeroth_frame);
   if (!success) {
 // We've gotten to the end of the stack.
 SetAllFramesFetched();
@@ -485,7 +490,7 @@
   const bool cfa_is_valid = true;
   unwind_frame_sp = std::make_shared(
   m_thread.shared_from_this(), m_frames.size(), idx, cfa, cfa_is_valid,
-  pc, StackFrame::Kind::Regular, nullptr);
+  pc, StackFrame::Kind::Regular, behaves_like_zeroth_frame, nullptr);
 
   // Create synthetic tail call frames between the previous frame and the
   // newly-found frame. The new frame's index may change after this call,
@@ -527,10 +532,11 @@
   while (unwind_sc.GetParentOfInlinedScope(
   curr_frame_address, next_frame_sc, next_frame_address)) {
 next_frame_sc.line_entry.ApplyFileMappings(target_sp);
-StackFrameSP frame_sp(
-new StackFrame(m_thread.shared_from_this(), m_frames.size(), idx,
-   unwind_frame_sp->GetRegisterContextSP(), cfa,
-   next_frame_address, &next_frame_sc));
+behaves_like_zeroth_frame = false;
+StackFrameSP frame_sp(new StackFrame(
+m_thread.shared_from_this(), m_frames.size(), idx,
+unwind_frame_sp->GetRegisterContextSP(), cfa, next_frame_address,
+behaves_like_zeroth_frame, &next_frame_sc));
 
 m_frames.push_back(frame_sp);

[Lldb-commits] [PATCH] D65414: Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

2019-08-02 Thread Stella Stamenova via Phabricator via lldb-commits

stella.stamenova added a comment.

Yes, it was! Thanks for catching that :)

The tests pass with the latest update.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65414/new/

https://reviews.llvm.org/D65414



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

[Lldb-commits] [lldb] r367691 - Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Joseph Tremoulet via lldb-commits

Author: josepht
Date: Fri Aug  2 09:53:42 2019
New Revision: 367691

URL: http://llvm.org/viewvc/llvm-project?rev=367691&view=rev
Log:
Fix PC adjustment in StackFrame::GetSymbolContext

Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrement when the given frame is a signal trap handler frame or the
parent of one, because the pc may not follow a call in these frames.
Accomplish this by adding a behaves_like_zeroth_frame field to
lldb_private::StackFrame, set to true for the zeroth frame, for
signal handler frames, and for parents of signal handler frames.

Also add logic to propagate the signal handler flag from UnwindPlan to
the FrameType on the RegisterContextLLDB it generates, and factor out a
helper to resolve symbol and address range for an Address now that we
need to invoke it in four places.

Reviewers: jasonmolenda, clayborg, jfb

Reviewed By: jasonmolenda

Subscribers: labath, dexonsmith, lldb-commits

Tags: #lldb

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

Added:
lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s
lldb/trunk/lit/Unwind/trap_frame_sym_ctx.test
Modified:
lldb/trunk/include/lldb/Core/Address.h
lldb/trunk/include/lldb/Target/StackFrame.h
lldb/trunk/include/lldb/Target/Unwind.h
lldb/trunk/source/Core/Address.cpp
lldb/trunk/source/Plugins/Process/Utility/HistoryUnwind.cpp
lldb/trunk/source/Plugins/Process/Utility/HistoryUnwind.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.h
lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
lldb/trunk/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
lldb/trunk/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.h
lldb/trunk/source/Target/StackFrame.cpp
lldb/trunk/source/Target/StackFrameList.cpp

Modified: lldb/trunk/include/lldb/Core/Address.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Address.h?rev=367691&r1=367690&r2=367691&view=diff
==
--- lldb/trunk/include/lldb/Core/Address.h (original)
+++ lldb/trunk/include/lldb/Core/Address.h Fri Aug  2 09:53:42 2019
@@ -338,6 +338,23 @@ public:
   bool ResolveAddressUsingFileSections(lldb::addr_t addr,
const SectionList *sections);
 
+  /// Resolve this address to its containing function and optionally get
+  /// that function's address range.
+  ///
+  /// \param[out] sym_ctx
+  /// The symbol context describing the function in which this address lies
+  ///
+  /// \parm[out] addr_range_ptr
+  /// Pointer to the AddressRange to fill in with the function's address
+  /// range.  Caller may pass null if they don't need the address range.
+  ///
+  /// \return
+  /// Returns \b false if the function/symbol could not be resolved
+  /// or if the address range was requested and could not be resolved;
+  /// returns \b true otherwise.
+  bool ResolveFunctionScope(lldb_private::SymbolContext &sym_ctx,
+lldb_private::AddressRange *addr_range_ptr = 
nullptr);
+
   /// Set the address to represent \a load_addr.
   ///
   /// The address will attempt to find a loaded section within \a target that

Modified: lldb/trunk/include/lldb/Target/StackFrame.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/StackFrame.h?rev=367691&r1=367690&r2=367691&view=diff
==
--- lldb/trunk/include/lldb/Target/StackFrame.h (original)
+++ lldb/trunk/include/lldb/Target/StackFrame.h Fri Aug  2 09:53:42 2019
@@ -108,17 +108,19 @@ public:
   StackFrame(const lldb::ThreadSP &thread_sp, lldb::user_id_t frame_idx,
  lldb::user_id_t concrete_frame_idx, lldb::addr_t cfa,
  bool cfa_is_valid, lldb::addr_t pc, Kind frame_kind,
- const SymbolContext *sc_ptr);
+ bool behaves_like_zeroth_frame, const SymbolContext *sc_ptr);
 
   StackFrame(const lldb::ThreadSP &thread_sp, lldb::user_id_t frame_idx,
  lldb::user_id_t concrete_frame_idx,
  const lldb::RegisterContextSP ®_context_sp, lldb::addr_t cfa,
- lldb::addr_t pc, const SymbolContext *sc_ptr);
+ lldb::addr_t pc, bool behaves_like_zeroth_frame,
+ const SymbolContext *sc_ptr);
 
   StackFrame(const lldb::ThreadSP &thread_sp, lldb::user_id_t frame_idx,
  lldb::user_id_t concrete_frame_idx,
  const lldb::RegisterContextSP ®_context_sp, lldb::addr_t cfa,
- const Address &pc, const SymbolContext *sc_ptr);
+ const Address &pc, bool behaves_like_zeroth_frame,
+ const SymbolContext *sc_ptr);
 
   ~StackFrame() override;
 
@@ -

[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Phabricator via Phabricator via lldb-commits

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL367691: Fix PC adjustment in StackFrame::GetSymbolContext 
(authored by josepht, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64993?vs=213067&id=213072#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64993/new/

https://reviews.llvm.org/D64993

Files:
  lldb/trunk/include/lldb/Core/Address.h
  lldb/trunk/include/lldb/Target/StackFrame.h
  lldb/trunk/include/lldb/Target/Unwind.h
  lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s
  lldb/trunk/lit/Unwind/trap_frame_sym_ctx.test
  lldb/trunk/source/Core/Address.cpp
  lldb/trunk/source/Plugins/Process/Utility/HistoryUnwind.cpp
  lldb/trunk/source/Plugins/Process/Utility/HistoryUnwind.h
  lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
  lldb/trunk/source/Plugins/Process/Utility/RegisterContextLLDB.h
  lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
  lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
  lldb/trunk/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
  lldb/trunk/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.h
  lldb/trunk/source/Target/StackFrame.cpp
  lldb/trunk/source/Target/StackFrameList.cpp

Index: lldb/trunk/source/Core/Address.cpp
===
--- lldb/trunk/source/Core/Address.cpp
+++ lldb/trunk/source/Core/Address.cpp
@@ -261,6 +261,24 @@
   return false; // Failed to resolve this address to a section offset value
 }
 
+/// if "addr_range_ptr" is not NULL, then fill in with the address range of the function.
+bool Address::ResolveFunctionScope(SymbolContext &sym_ctx,
+   AddressRange *addr_range_ptr) {
+  constexpr SymbolContextItem resolve_scope =
+eSymbolContextFunction | eSymbolContextSymbol;
+
+  if (!(CalculateSymbolContext(&sym_ctx, resolve_scope) & resolve_scope)) {
+if (addr_range_ptr)
+  addr_range_ptr->Clear();
+   return false;
+  }
+
+  if (!addr_range_ptr)
+return true;
+
+  return sym_ctx.GetAddressRange(resolve_scope, 0, false, *addr_range_ptr);
+}
+
 ModuleSP Address::GetModule() const {
   lldb::ModuleSP module_sp;
   SectionSP section_sp(GetSection());
Index: lldb/trunk/source/Target/StackFrame.cpp
===
--- lldb/trunk/source/Target/StackFrame.cpp
+++ lldb/trunk/source/Target/StackFrame.cpp
@@ -51,14 +51,16 @@
 StackFrame::StackFrame(const ThreadSP &thread_sp, user_id_t frame_idx,
user_id_t unwind_frame_index, addr_t cfa,
bool cfa_is_valid, addr_t pc, StackFrame::Kind kind,
+   bool behaves_like_zeroth_frame,
const SymbolContext *sc_ptr)
 : m_thread_wp(thread_sp), m_frame_index(frame_idx),
   m_concrete_frame_index(unwind_frame_index), m_reg_context_sp(),
   m_id(pc, cfa, nullptr), m_frame_code_addr(pc), m_sc(), m_flags(),
   m_frame_base(), m_frame_base_error(), m_cfa_is_valid(cfa_is_valid),
-  m_stack_frame_kind(kind), m_variable_list_sp(),
-  m_variable_list_value_objects(), m_recognized_frame_sp(), m_disassembly(),
-  m_mutex() {
+  m_stack_frame_kind(kind),
+  m_behaves_like_zeroth_frame(behaves_like_zeroth_frame),
+  m_variable_list_sp(), m_variable_list_value_objects(),
+  m_recognized_frame_sp(), m_disassembly(), m_mutex() {
   // If we don't have a CFA value, use the frame index for our StackID so that
   // recursive functions properly aren't confused with one another on a history
   // stack.
@@ -75,15 +77,17 @@
 StackFrame::StackFrame(const ThreadSP &thread_sp, user_id_t frame_idx,
user_id_t unwind_frame_index,
const RegisterContextSP ®_context_sp, addr_t cfa,
-   addr_t pc, const SymbolContext *sc_ptr)
+   addr_t pc, bool behaves_like_zeroth_frame,
+   const SymbolContext *sc_ptr)
 : m_thread_wp(thread_sp), m_frame_index(frame_idx),
   m_concrete_frame_index(unwind_frame_index),
   m_reg_context_sp(reg_context_sp), m_id(pc, cfa, nullptr),
   m_frame_code_addr(pc), m_sc(), m_flags(), m_frame_base(),
   m_frame_base_error(), m_cfa_is_valid(true),
-  m_stack_frame_kind(StackFrame::Kind::Regular), m_variable_list_sp(),
-  m_variable_list_value_objects(), m_recognized_frame_sp(), m_disassembly(),
-  m_mutex() {
+  m_stack_frame_kind(StackFrame::Kind::Regular),
+  m_behaves_like_zeroth_frame(behaves_like_zeroth_frame),
+  m_variable_list_sp(), m_variable_list_value_objects(),
+  m_recognized_frame_sp(), m_disassembly(), m_mutex() {
   if (sc_ptr != nullptr) {
 m_sc = *sc_ptr;
 m_flags.Set(m_sc.GetResolve

[Lldb-commits] [PATCH] D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP]

2019-08-02 Thread Michał Górny via Phabricator via lldb-commits

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



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:737
+  for (auto it = m_threads.begin(); it != m_threads.end(); ++it) {
+if (*it && ((*it)->GetID() == thread_id)) {
+  m_threads.erase(it);

jfb wrote:
> mgorny wrote:
> > labath wrote:
> > > It looks like the rest of the code assumes (as I think it should) that 
> > > the thread list does not contain null pointers. See e.g. the loop on line 
> > > 276.
> > For the record, I've copied it from Linux ;-P.
> Are you serious? Because you absolutely cannot copy code from Linux into LLVM.
I meant LLDB Linux Process plugin.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6/new/

https://reviews.llvm.org/D6



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

[Lldb-commits] [PATCH] D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP]

2019-08-02 Thread Jim Ingham via Phabricator via lldb-commits

jingham added inline comments.



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:737
+  for (auto it = m_threads.begin(); it != m_threads.end(); ++it) {
+if (*it && ((*it)->GetID() == thread_id)) {
+  m_threads.erase(it);

mgorny wrote:
> jfb wrote:
> > mgorny wrote:
> > > labath wrote:
> > > > It looks like the rest of the code assumes (as I think it should) that 
> > > > the thread list does not contain null pointers. See e.g. the loop on 
> > > > line 276.
> > > For the record, I've copied it from Linux ;-P.
> > Are you serious? Because you absolutely cannot copy code from Linux into 
> > LLVM.
> I meant LLDB Linux Process plugin.
I believe Michal means he copied it from the Linux NativeProcess implementation 
in lldb to the NetBSD Process plugin in lldb.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6/new/

https://reviews.llvm.org/D6



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

[Lldb-commits] [PATCH] D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP]

2019-08-02 Thread JF Bastien via Phabricator via lldb-commits

jfb added inline comments.



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:737
+  for (auto it = m_threads.begin(); it != m_threads.end(); ++it) {
+if (*it && ((*it)->GetID() == thread_id)) {
+  m_threads.erase(it);

jingham wrote:
> mgorny wrote:
> > jfb wrote:
> > > mgorny wrote:
> > > > labath wrote:
> > > > > It looks like the rest of the code assumes (as I think it should) 
> > > > > that the thread list does not contain null pointers. See e.g. the 
> > > > > loop on line 276.
> > > > For the record, I've copied it from Linux ;-P.
> > > Are you serious? Because you absolutely cannot copy code from Linux into 
> > > LLVM.
> > I meant LLDB Linux Process plugin.
> I believe Michal means he copied it from the Linux NativeProcess 
> implementation in lldb to the NetBSD Process plugin in lldb.
OK, thank you for clarifying.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6/new/

https://reviews.llvm.org/D6



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

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions.

2019-08-02 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

In D65646#1612436 , @aprantl wrote:

> I have a question based on my half-knowledge about the expression evaluator: 
> I thought that we already wrote out a temporary file for the expression in 
> order to support `expr -g`? Is this orthogonal or do we now have to ways of 
> pretending there is a source file backing up the expression?

The file creation happens a little above the change to pass in a memory file:

  // We also want a real file on disk if we generate full debug info.
  should_create_file |= m_compiler->getCodeGenOpts().getDebugInfo() ==
codegenoptions::FullDebugInfo;

around line 891.  Raphael's change doesn't change whether we emit this source 
file or not.

But it seem weird that this will make every expression seem to come from the 
same file and line.  It would be really nice to be able to set breakpoints in 
compiled expressions, but if all the files think they have the same source file 
& starting line, this will be harder to get working.

Note, however, the creation of the source file & tracing back from the 
debug_line that we insert when we JIT the expression to this source file seems 
broken, however.  If I do:

  (lldb) expr --top-level -- int $foo(int) { (int) printf("I am here.\n"); }
  (lldb) b s -n printf
  Breakpoint 3: where = libsystem_c.dylib`printf, address = 0x7fff616588ec
  (lldb) expr -i 0 -- $foo(10)
  1 location added to breakpoint 2
  error: Execution was interrupted, reason: breakpoint 2.1.
  The process has been left at the point where it was interrupted, use "thread 
return -x" to return to the state before expression evaluation.
  Process 3708 stopped
  * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  frame #0: 0x000100104b1b $__lldb_expr1`$foo(int) at Parse:1
  Target 0: (something) stopped.

I should have seen the source code for $foo, but we don't seem to have found 
the file.  So something is broken in this process.

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65646/new/

https://reviews.llvm.org/D65646

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

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik created this revision.
shafik added reviewers: aprantl, jasonmolenda, JDevlieghere.
Herald added a reviewer: EricWF.
Herald added a subscriber: christof.

We have been seeing increased reports of performance issue around large project 
and formatting std::function variables especially in functions signatures in 
back traces. There are some possible fixes but exploring those fixes may take 
time and it is better to temporarily disable the formatter due to its impact 
and re-enable it once we have a fix.


https://reviews.llvm.org/D65666

Files:
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
  source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp


Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,
Index: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -23,6 +23,7 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed 
by LLDB"""


Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,
Index: packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -23,6 +23,7 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed by LLDB"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Adrian Prantl via Phabricator via lldb-commits

aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.



Comment at: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py:26
 
+@skipIf
 @add_test_categories(["libc++"])

I didn't know that worked! Please also add a comment that explains *why* this 
test is skipped.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65666/new/

https://reviews.llvm.org/D65666



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

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik updated this revision to Diff 213090.
shafik added a comment.

Adding as suggested.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65666/new/

https://reviews.llvm.org/D65666

Files:
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
  source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp


Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,
Index: 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ 
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -23,6 +23,9 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+# Temporarily skipping for everywhere b/c we are disabling the 
std::function formatter
+# due to performance issues but plan on turning it back on once they are 
addressed.
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed 
by LLDB"""


Index: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,
Index: packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -23,6 +23,9 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+# Temporarily skipping for everywhere b/c we are disabling the std::function formatter
+# due to performance issues but plan on turning it back on once they are addressed.
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed by LLDB"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik added a comment.

@aprantl I did not know either until I looked at decorators.py and it says:

  # @skipIf, skip for all platform/compiler/arch,


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65666/new/

https://reviews.llvm.org/D65666



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

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Please also add a comment to `formatters::LibcxxFunctionSummaryProvider` saying 
that it's currently not being registered.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65666/new/

https://reviews.llvm.org/D65666



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

[Lldb-commits] [lldb] r367701 - [Formatters] Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Shafik Yaghmour via lldb-commits

Author: shafik
Date: Fri Aug  2 11:16:04 2019
New Revision: 367701

URL: http://llvm.org/viewvc/llvm-project?rev=367701&view=rev
Log:
[Formatters] Temporarily disable libc++ std::function formatter due to 
performance issue

Summary: We have been seeing increased reports of performance issue around 
large project and formatting std::function variables especially in functions 
signatures in back traces. There are some possible fixes but exploring those 
fixes may take time and it is better to temporarily disable the formatter due 
to its impact and re-enable it once we have a fix.

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py?rev=367701&r1=367700&r2=367701&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
 Fri Aug  2 11:16:04 2019
@@ -21,6 +21,9 @@ class LibCxxFunctionTestCase(TestBase):
 var.SetPreferSyntheticValue(True)
 return var
 
+# Temporarily skipping for everywhere b/c we are disabling the 
std::function formatter
+# due to performance issues but plan on turning it back on once they are 
addressed.
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed 
by LLDB"""

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp?rev=367701&r1=367700&r2=367701&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
(original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp Fri Aug  
2 11:16:04 2019
@@ -566,12 +566,6 @@ static void LoadLibCxxFormatters(lldb::T
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,


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

[Lldb-commits] [PATCH] D65666: Temporarily disable libc++ std::function formatter due to performance issue

2019-08-02 Thread Shafik Yaghmour via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367701: [Formatters] Temporarily disable libc++ 
std::function formatter due to… (authored by shafik, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65666?vs=213090&id=213094#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65666/new/

https://reviews.llvm.org/D65666

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
  lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp


Index: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -21,6 +21,9 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+# Temporarily skipping for everywhere b/c we are disabling the 
std::function formatter
+# due to performance issues but plan on turning it back on once they are 
addressed.
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed 
by LLDB"""
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,


Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
@@ -21,6 +21,9 @@
 var.SetPreferSyntheticValue(True)
 return var
 
+# Temporarily skipping for everywhere b/c we are disabling the std::function formatter
+# due to performance issues but plan on turning it back on once they are addressed.
+@skipIf
 @add_test_categories(["libc++"])
 def test(self):
 """Test that std::function as defined by libc++ is correctly printed by LLDB"""
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -566,12 +566,6 @@
   ConstString("^(std::__[[:alnum:]]+::)weak_ptr<.+>(( )?&)?$"),
   stl_synth_flags, true);
 
-  AddCXXSummary(
-  cpp_category_sp, lldb_private::formatters::LibcxxFunctionSummaryProvider,
-  "libc++ std::function summary provider",
-  ConstString("^std::__[[:alnum:]]+::function<.+>$"), stl_summary_flags,
-  true);
-
   stl_summary_flags.SetDontShowChildren(false);
   stl_summary_flags.SetSkipPointers(false);
   AddCXXSummary(cpp_category_sp,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Hey Joseph,

The test `trap_frame_sym_ctx` is failing on GreenDragon. Can you please have a 
look?

http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/32449/testReport/junit/LLDB/Unwind/trap_frame_sym_ctx_test/


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64993/new/

https://reviews.llvm.org/D64993



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

[Lldb-commits] [lldb] r367706 - Use rip-relative addressing in asm test

2019-08-02 Thread Joseph Tremoulet via lldb-commits

Author: josepht
Date: Fri Aug  2 12:06:15 2019
New Revision: 367706

URL: http://llvm.org/viewvc/llvm-project?rev=367706&view=rev
Log:
Use rip-relative addressing in asm test

The absolute form is an error when targeting Darwin.

Modified:
lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s

Modified: lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s?rev=367706&r1=367705&r2=367706&view=diff
==
--- lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s (original)
+++ lldb/trunk/lit/Unwind/Inputs/trap_frame_sym_ctx.s Fri Aug  2 12:06:15 2019
@@ -18,7 +18,7 @@ asm_main:
 
 # install tramp as return address
 # (similar to signal return trampolines on some platforms)
-leaqtramp, %rax
+leaqtramp(%rip), %rax
 pushq   %rax
 jmp bar # call, with return address pointing to tramp
 


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

[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Joseph Tremoulet via Phabricator via lldb-commits

JosephTremoulet added a comment.

In D64993#1612746 , @JDevlieghere 
wrote:

> Hey Joseph,
>
> The test `trap_frame_sym_ctx` is failing on GreenDragon. Can you please have 
> a look?
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/32449/testReport/junit/LLDB/Unwind/trap_frame_sym_ctx_test/

Sorry about that.  Hopefully fixed by r367706.

Thanks for the heads-up, though I'm surprised I didn't see one from the bot on 
either email or IRC; is it not sending them out, or am I just not looking in 
the right places?

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64993/new/

https://reviews.llvm.org/D64993

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

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions.

2019-08-02 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor added a comment.

> Is this orthogonal or do we now have to ways of pretending there is a source 
> file backing up the expression?

Jim already answered this, but this patch only changes the file names of our 
expression and pretends for the sake of diagnostics that we are in a separate 
file for the user code.

> But it seem weird that this will make every expression seem to come from the 
> same file and line.

What about enumerating the expression file names we print? E.g. ``, ``?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65646/new/

https://reviews.llvm.org/D65646



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

[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-02 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D64993#1612825 , @JosephTremoulet 
wrote:

> In D64993#1612746 , @JDevlieghere 
> wrote:
>
> > Hey Joseph,
> >
> > The test `trap_frame_sym_ctx` is failing on GreenDragon. Can you please 
> > have a look?
> >
> > http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/32449/testReport/junit/LLDB/Unwind/trap_frame_sym_ctx_test/
>
>
> Sorry about that.  Hopefully fixed by r367706.


Thanks, the bot is green again :-)

> Thanks for the heads-up, though I'm surprised I didn't see one from the bot 
> on either email or IRC; is it not sending them out, or am I just not looking 
> in the right places?

Interesting. I'll check with the infrastructure team.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64993/new/

https://reviews.llvm.org/D64993



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

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions.

2019-08-02 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

That would be fine.  In the swift REPL, we increment the line number so that it 
appears that all the expressions are one contiguous source file.  But I think 
for the expression parser treating each expression as a separate file is a 
better fiction.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65646/new/

https://reviews.llvm.org/D65646



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

[Lldb-commits] [PATCH] D65677: [VirtualFileSystem] Support encoding a current working directory in a VFS mapping.

2019-08-02 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: bkramer, bruno, vsapsai, sammccall.
Herald added subscribers: lldb-commits, dexonsmith, hiraditya.
Herald added projects: LLDB, LLVM.

For reproducers it is useful to encode the notion of the current working 
directory in the VFS mapping. This enables us to handle relative files 
transparently, as long as the current working directory doesn't change over 
time.

This change is motivated by a current bug in LLDB's reproducers. When a 
relative path to a binary is passed to the debugger, we fail to resolve it 
during reproducer replay, because the resolved (absolute) path doesn't match 
any entry in the VFS.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65677

Files:
  llvm/include/llvm/Support/VirtualFileSystem.h
  llvm/lib/Support/VirtualFileSystem.cpp
  llvm/unittests/Support/VirtualFileSystemTest.cpp

Index: llvm/unittests/Support/VirtualFileSystemTest.cpp
===
--- llvm/unittests/Support/VirtualFileSystemTest.cpp
+++ llvm/unittests/Support/VirtualFileSystemTest.cpp
@@ -1994,3 +1994,42 @@
   EXPECT_EQ(FS->getRealPath("/non_existing", RealPath),
 errc::no_such_file_or_directory);
 }
+
+TEST_F(VFSFromYAMLTest, CurrentWorkingDirectory) {
+  IntrusiveRefCntPtr Lower(new DummyFileSystem());
+  Lower->addDirectory("//root/");
+  Lower->addDirectory("//root/foo");
+  Lower->addRegularFile("//root/foo/a");
+  Lower->addRegularFile("//root/foo/b");
+  IntrusiveRefCntPtr FS = getFromYAMLString(
+  "{ 'use-external-names': false,\n"
+  "  'current-working-directory': '//root/bar'\n"
+  "  'roots': [\n"
+  "{\n"
+  "  'type': 'directory',\n"
+  "  'name': '//root/',\n"
+  "  'contents': [ {\n"
+  "  'type': 'file',\n"
+  "  'name': 'bar/a',\n"
+  "  'external-contents': '//root/foo/a'\n"
+  "}\n"
+  "  ]\n"
+  "}\n"
+  "]\n"
+  "}",
+  Lower);
+  ASSERT_TRUE(FS.get() != nullptr);
+
+  llvm::ErrorOr CWD = FS->getCurrentWorkingDirectory();
+  ASSERT_FALSE(CWD.getError());
+  EXPECT_EQ(*CWD, "//root/bar");
+
+  llvm::ErrorOr Status = FS->status("./a");
+  ASSERT_FALSE(Status.getError());
+  EXPECT_TRUE(Status->isStatusKnown());
+  EXPECT_FALSE(Status->isDirectory());
+  EXPECT_TRUE(Status->isRegularFile());
+  EXPECT_FALSE(Status->isSymlink());
+  EXPECT_FALSE(Status->isOther());
+  EXPECT_TRUE(Status->exists());
+}
Index: llvm/lib/Support/VirtualFileSystem.cpp
===
--- llvm/lib/Support/VirtualFileSystem.cpp
+++ llvm/lib/Support/VirtualFileSystem.cpp
@@ -1035,11 +1035,17 @@
 
 llvm::ErrorOr
 RedirectingFileSystem::getCurrentWorkingDirectory() const {
+  if (!CurrentWorkingDirectory.empty())
+return CurrentWorkingDirectory;
   return ExternalFS->getCurrentWorkingDirectory();
 }
 
 std::error_code
 RedirectingFileSystem::setCurrentWorkingDirectory(const Twine &Path) {
+  // Changing the current working directory might have side effects for the
+  // external file system. Unset the special current working directory and have
+  // the external FS deal with them from now on.
+  CurrentWorkingDirectory.clear();
   return ExternalFS->setCurrentWorkingDirectory(Path);
 }
 
@@ -1473,6 +1479,7 @@
 KeyStatusPair("use-external-names", false),
 KeyStatusPair("overlay-relative", false),
 KeyStatusPair("fallthrough", false),
+KeyStatusPair("current-working-directory", false),
 KeyStatusPair("roots", true),
 };
 
@@ -1533,6 +1540,12 @@
   } else if (Key == "fallthrough") {
 if (!parseScalarBool(I.getValue(), FS->IsFallthrough))
   return false;
+  } else if (Key == "current-working-directory") {
+StringRef CurrentWorkingDirectory;
+SmallString<256> Storage;
+if (!parseScalarString(I.getValue(), CurrentWorkingDirectory, Storage))
+  return false;
+FS->setCurrentWorkingDirectory(CurrentWorkingDirectory);
   } else {
 llvm_unreachable("key missing from Keys");
   }
@@ -1874,7 +1887,7 @@
 
   void write(ArrayRef Entries, Optional UseExternalNames,
  Optional IsCaseSensitive, Optional IsOverlayRelative,
- StringRef OverlayDir);
+ StringRef OverlayDir, StringRef CurrentWorkingDirectory);
 };
 
 } // namespace
@@ -1932,6 +1945,7 @@
Optional UseExternalNames,
Optional IsCaseSensitive,
Optional IsOverlayRelative,
+   StringRef CurrentWorkingDirectory,
StringRef OverlayDir) {
   using namespace llvm::sys;
 
@@ -1949,6 +1963,9 @@
 OS << "  'overlay-relative': '" << (UseOverlayRelative ? "true" : "false")
<< "',\n";
   }
+  if (!CurrentWorkingDirectory.empty())
+OS << "  'current-working-directory': \""
+

[Lldb-commits] [PATCH] D65611: [Driver] Expand the target in the driver.

2019-08-02 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D65611#1611724 , @labath wrote:

> The details of how our FS capture works have unfortunately, swapped out of my 
> memory, but... isn't this the sort of thing that should already be handled by 
> the filesystem capture/replay machinery? It sounds to me like it could/should 
> remember what the CWD at the time of capture was, and then, when replaying, 
> point the fake CWD into the right place in the captured filesystem image. 
> This way, the relative paths should resolve the same way as they originally 
> did.


This functionality is not currently present in the VFS, but I've created a 
patch to support it: https://reviews.llvm.org/D65677

> This patch just moves the place where this VFS definiciency manifests itself 
> (*), so that it does not pose a problem for this particular use case. 
> However, I'd be surprised if this is the only relative path that is being 
> resolved inconsistently, and I think a more general solution would be more 
> appropriate.
> 
> (*) What I mean by that, is that the `SBFileSpec::ResolvePath` will still end 
> up returning a different value during replay than what it did originally. 
> However, because the data leaves the SB boundary, and then crosses it back in 
> through SBStream::Printf, we lose track of the fact that this is the same 
> data, and we capture it as a constant. Before this patch, the data was always 
> under the SB boundary, and so we were assuming that the data flow will be 
> identical during record&replay, which it wasn't, and that is the real bug, I 
> think.




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65611/new/

https://reviews.llvm.org/D65611



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

[Lldb-commits] [lldb] r367726 - Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

2019-08-02 Thread Shafik Yaghmour via lldb-commits

Author: shafik
Date: Fri Aug  2 14:41:50 2019
New Revision: 367726

URL: http://llvm.org/viewvc/llvm-project?rev=367726&view=rev
Log:
Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

Summary:
The change https://reviews.llvm.org/D55575 modified 
ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); 
this caused a regression since the existing code in 
DWARFASTParserClang::ParseChildParameters is called with the containing 
DeclContext. So when end up with cases where we are parsing a parameter for a 
member function and the parameter is added to the CXXRecordDecl as opposed to 
the CXXMethodDecl. This example is given in the regression test 
TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a 
modules build leads to assert on setting a breakpoint in a member function with 
non primitive parameters. This scenario would be common when debugging LLDB or 
clang.

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

Added:

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=367726&r1=367725&r2=367726&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Fri Aug  2 14:41:50 2019
@@ -395,7 +395,8 @@ public:
   clang::ParmVarDecl *CreateParameterDeclaration(clang::DeclContext *decl_ctx,
  const char *name,
  const CompilerType 
¶m_type,
- int storage);
+ int storage,
+ bool add_decl=false);
 
   void SetFunctionParameters(clang::FunctionDecl *function_decl,
  clang::ParmVarDecl **params, unsigned num_params);

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile?rev=367726&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
 Fri Aug  2 14:41:50 2019
@@ -0,0 +1,6 @@
+LEVEL = ../../../make
+
+CXX_SOURCES = main.cpp a.cpp
+CFLAGS_EXTRAS = $(MANDATORY_CXXMODULE_BUILD_CFLAGS)
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py?rev=367726&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
 Fri Aug  2 14:41:50 2019
@@ -0,0 +1,26 @@
+"""
+This is a regression test for an assert that happens while setting a 
breakpoint.
+The root cause of the assert was attempting to add a ParmVarDecl to a 
CXXRecordDecl
+when it should have been added to a CXXMethodDecl.
+
+We can reproduce with a module build and setting a breakpoint in a member 
func

[Lldb-commits] [PATCH] D65414: Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

2019-08-02 Thread Shafik Yaghmour via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367726: Fix ClangASTContext::CreateParameterDeclaration to 
not call addDecl (authored by shafik, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65414?vs=212884&id=213132#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65414/new/

https://reviews.llvm.org/D65414

Files:
  lldb/trunk/include/lldb/Symbol/ClangASTContext.h
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
  lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp

Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../../make
+
+CXX_SOURCES = main.cpp a.cpp
+CFLAGS_EXTRAS = $(MANDATORY_CXXMODULE_BUILD_CFLAGS)
+
+include $(LEVEL)/Makefile.rules
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
@@ -0,0 +1,3 @@
+module A {
+  header "a.h"
+}
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h
@@ -0,0 +1,7 @@
+struct A {
+  bool b(int x);
+};
+
+struct B {
+  bool member_func_a(A a);
+};
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp
@@ -0,0 +1,15 @@
+#include "a.h"
+#include 
+
+bool foo() {
+  A a1;
+  B b1;
+
+  return b1.member_func_a(a1); // break here
+}
+
+int main() {
+  int x = 0;
+
+  return foo();
+}
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp
@@ -0,0 +1,14 @@
+#include "a.h"
+
+bool A::b(int x) {
+  if (x)
+return true;
+
+  return false;
+}
+
+bool B::member_func_a(A a) {
+  return a.b(10); // We will try and add a breakpoint here which
+  // trigger an assert since we will attempt to
+  // to add ParamVarDecl a to CXXRecordDecl A
+};
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
@@ -0,0 +1,26 @@
+"""
+This is a regression test for an assert that happens while setting a breakpoint.
+The root cause of the assert was attempting to add a ParmVarDecl t

Re: [Lldb-commits] [lldb] r367726 - Fix ClangASTContext::CreateParameterDeclaration to not call addDecl

2019-08-02 Thread Davide Italiano via lldb-commits

On Fri, Aug 2, 2019 at 2:40 PM Shafik Yaghmour via lldb-commits
 wrote:
>
> Author: shafik
> Date: Fri Aug  2 14:41:50 2019
> New Revision: 367726
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367726&view=rev
> Log:
> Fix ClangASTContext::CreateParameterDeclaration to not call addDecl
>
> Summary:
> The change https://reviews.llvm.org/D55575 modified 
> ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); 
> this caused a regression since the existing code in 
> DWARFASTParserClang::ParseChildParameters is called with the containing 
> DeclContext. So when end up with cases where we are parsing a parameter for a 
> member function and the parameter is added to the CXXRecordDecl as opposed to 
> the CXXMethodDecl. This example is given in the regression test 
> TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a 
> modules build leads to assert on setting a breakpoint in a member function 
> with non primitive parameters. This scenario would be common when debugging 
> LLDB or clang.
>
> Differential Revision: https://reviews.llvm.org/D65414
>
> Added:
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/Makefile
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/TestBreakpointInMemberFuncWNonPrimitiveParams.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.cpp
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/a.h
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/main.cpp
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/breakpoint_in_member_func_w_non_primitive_params/module.modulemap
> Modified:
> lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
> lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
> lldb/trunk/source/Symbol/ClangASTContext.cpp
>
> Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=367726&r1=367725&r2=367726&view=diff
> ==
> --- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
> +++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Fri Aug  2 14:41:50 2019
> @@ -395,7 +395,8 @@ public:
>clang::ParmVarDecl *CreateParameterDeclaration(clang::DeclContext 
> *decl_ctx,
>   const char *name,
>   const CompilerType 
> ¶m_type,
> - int storage);
> + int storage,
> + bool add_decl=false);
>

Sorry for arriving late to the party, but what's the reason for this
parameter? Maybe we should add a comment, given that the commit message
doesn't really explain why the PDB parser skips adding the declaration either?

Thanks,

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

[Lldb-commits] [PATCH] D65611: [Driver] Expand the target in the driver.

2019-08-02 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

Also be careful if the user uses a symlink to not resolve the link. If a user 
tries to debug clang++:

  $ ls -AFlG 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang*
  -rwxr-xr-x  1 root  wheel  8156 Jul 12 21:48 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang*
  lrwxr-xr-x  1 root  wheel 5 Jul 25 07:57 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++@
 -> clang

We don't want to resolve it to "clang" or it will change the behavior for any 
program that checks argv[0] and doesn't something different depending on what 
that values is.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65611/new/

https://reviews.llvm.org/D65611



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

[Lldb-commits] [PATCH] D65647: Fix line table resolution near the end of a section

2019-08-02 Thread Greg Clayton via Phabricator via lldb-commits

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

I vote to not add any API calls with allow_section_end and just take care of 
this in source/Symbol/LineTable.cpp. All of my inline comments will reflect 
this notion.




Comment at: include/lldb/Core/Module.h:683-684
 
-  bool ResolveFileAddress(lldb::addr_t vm_addr, Address &so_addr);
+  bool ResolveFileAddress(lldb::addr_t vm_addr, Address &so_addr,
+  bool allow_section_end = false);
 

revert



Comment at: include/lldb/Core/Section.h:74-80
+  /// Look up the given file address in the contained sections. Return a
+  /// section-relative Address object if a section is found. if
+  /// allow_section_end is true, an address pointing past the end of a section
+  /// is permitted and resolved relative to the section which ends at the given
+  /// address.
+  llvm::Optional ResolveFileAddress(lldb::addr_t file_addr,
+ bool allow_section_end) const;

revert



Comment at: include/lldb/Core/Section.h:133-137
+  /// Return true iff this section contains the given file address. If
+  /// allow_section_end is true, the function returns true also for address
+  /// pointing past the end of the section.
+  bool ContainsFileAddress(lldb::addr_t vm_addr,
+   bool allow_section_end = false) const;

revert



Comment at: source/Core/Module.cpp:426-440
+bool Module::ResolveFileAddress(lldb::addr_t vm_addr, Address &so_addr,
+bool allow_section_end) {
   std::lock_guard guard(m_mutex);
   static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
   Timer scoped_timer(func_cat,
  "Module::ResolveFileAddress (vm_addr = 0x%" PRIx64 ")",
  vm_addr);

revert



Comment at: source/Core/Section.cpp:270-276
+bool Section::ContainsFileAddress(addr_t vm_addr,
+  bool allow_section_end) const {
   const addr_t file_addr = GetFileAddress();
   if (file_addr != LLDB_INVALID_ADDRESS && !IsThreadSpecific()) {
 if (file_addr <= vm_addr) {
   const addr_t offset = (vm_addr - file_addr) * m_target_byte_size;
+  return offset < GetByteSize() + (allow_section_end ? 1 : 0);

revert



Comment at: source/Core/Section.cpp:590-603
+llvm::Optional
+SectionList::ResolveFileAddress(addr_t file_addr,
+bool allow_section_end) const {
+  for (const SectionSP §ion_sp : m_sections) {
+if (section_sp->ContainsFileAddress(file_addr, allow_section_end)) {
+  Address addr;
+  section_sp->ResolveContainedAddress(

revert



Comment at: source/Symbol/LineTable.cpp:247-249
+if (module_sp && module_sp->ResolveFileAddress(
+ entry.file_addr, line_entry.range.GetBaseAddress(),
+ /*allow_section_end = */ entry.is_terminal_entry)) {

Take care of backing up the entry address if this is the last entry so we don't 
need any of the other API changes:

```
lldb::addr_t file_addr = entry.file_addr - (entry.is_terminal_entry ? 1 : 0);
if (module_sp && module_sp->ResolveFileAddress(file_addr, 
line_entry.range.GetBaseAddress())) {
  if (entry.is_terminal_entry) 
line_entry.range.GetBaseAddress().Slide(1);
``` 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65647/new/

https://reviews.llvm.org/D65647



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

[Lldb-commits] [PATCH] D61090: [SBHostOS] Remove getting the python script interpreter path

2019-08-02 Thread Greg Clayton via Phabricator via lldb-commits

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

We can't change functionality in our API. Fine to add something to SBDebugger, 
but we can't just disable a call that used to work in SBHostOS.




Comment at: lldb/source/API/SBHostOS.cpp:63
   case ePathTypePythonDir:
-#ifndef LLDB_DISABLE_PYTHON
-fspec = ScriptInterpreterPython::GetPythonDir();
-#endif
+// Deprecated. Use SBCommandInpterpreter::GetScriptModuleDirectory instead.
 break;

So now we don't return anything here? That is bad. this can break older scripts 
and violates our API. Deprecation is not the same as disabling the 
functionality that once worked.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61090/new/

https://reviews.llvm.org/D61090



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

[Lldb-commits] [PATCH] D65682: Give a little more info when "run_to_x_breakpoint" fails

2019-08-02 Thread Jim Ingham via Phabricator via lldb-commits

jingham created this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

We failure was a little bit terse.  Say whether we exited, hit another 
breakpoint/crashed, etc.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65682

Files:
  lldb/packages/Python/lldbsuite/test/lldbutil.py


Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -778,7 +778,18 @@
 threads = get_threads_stopped_at_breakpoint(
 process, bkpt)
 
+# Check that we stopped at our breakpoint.  Try to separate failure 
reasons:
+test.assertNotEqual(process.GetState(), lldb.eStateExited, "Process exited 
before stopping at breakpoint.")
+if len(threads) == 0:
+(bkpts, crashed, signaled) = ([], [], [])
+sort_stopped_threads(process, 
+ breakpoint_threads = bkpts, 
+ crashed_threads = crashed, 
+ signal_threads = signaled)
+test.fail("Stopped for another reason: Breakpoint: %d Signaled: %d 
Crashed: %d"%(len(bkpts), len(crashed), len(signaled)))
+
 test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at 
breakpoint, %d did."%(len(threads)))
+
 thread = threads[0]
 return (target, process, thread, bkpt)
 


Index: lldb/packages/Python/lldbsuite/test/lldbutil.py
===
--- lldb/packages/Python/lldbsuite/test/lldbutil.py
+++ lldb/packages/Python/lldbsuite/test/lldbutil.py
@@ -778,7 +778,18 @@
 threads = get_threads_stopped_at_breakpoint(
 process, bkpt)
 
+# Check that we stopped at our breakpoint.  Try to separate failure reasons:
+test.assertNotEqual(process.GetState(), lldb.eStateExited, "Process exited before stopping at breakpoint.")
+if len(threads) == 0:
+(bkpts, crashed, signaled) = ([], [], [])
+sort_stopped_threads(process, 
+ breakpoint_threads = bkpts, 
+ crashed_threads = crashed, 
+ signal_threads = signaled)
+test.fail("Stopped for another reason: Breakpoint: %d Signaled: %d Crashed: %d"%(len(bkpts), len(crashed), len(signaled)))
+
 test.assertTrue(len(threads) == 1, "Expected 1 thread to stop at breakpoint, %d did."%(len(threads)))
+
 thread = threads[0]
 return (target, process, thread, bkpt)
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65691: Various build fixes for lldb on MinGW

2019-08-02 Thread Haibo Huang via Phabricator via lldb-commits

hhb created this revision.
Herald added subscribers: lldb-commits, mstorsjo.
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65691

Files:
  lldb/include/lldb/Host/windows/PosixApi.h
  lldb/source/Host/windows/FileSystem.cpp
  lldb/source/Initialization/SystemInitializerCommon.cpp
  
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/tools/driver/Platform.h
  lldb/tools/lldb-vscode/VSCode.cpp
  lldb/tools/lldb-vscode/lldb-vscode.cpp

Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -50,7 +50,9 @@
 #include "VSCode.h"
 
 #if defined(_WIN32)
+#ifndef PATH_MAX
 #define PATH_MAX MAX_PATH
+#endif
 typedef int socklen_t;
 constexpr const char *dev_null_path = "nul";
 
Index: lldb/tools/lldb-vscode/VSCode.cpp
===
--- lldb/tools/lldb-vscode/VSCode.cpp
+++ lldb/tools/lldb-vscode/VSCode.cpp
@@ -16,7 +16,9 @@
 
 #if defined(_WIN32)
 #define NOMINMAX
+#ifndef __MINGW32__
 #include 
+#endif // __MINGW32__
 #include 
 #include 
 #endif
Index: lldb/tools/driver/Platform.h
===
--- lldb/tools/driver/Platform.h
+++ lldb/tools/driver/Platform.h
@@ -15,6 +15,10 @@
 #if defined(_MSC_VER)
 #include 
 #endif
+#if defined(__MINGW32__)
+// pid_t
+#include 
+#endif
 #include "lldb/Host/windows/windows.h"
 #include 
 
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -16,6 +16,10 @@
 #include 
 #include 
 #endif
+#ifdef __MINGW32__
+// usleep
+#include 
+#endif
 #include 
 #include 
 #include 
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
@@ -16,6 +16,11 @@
 #include 
 #include 
 
+#ifdef __MINGW32__
+// usleep
+#include 
+#endif
+
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Threading.h"
 
Index: lldb/source/Initialization/SystemInitializerCommon.cpp
===
--- lldb/source/Initialization/SystemInitializerCommon.cpp
+++ lldb/source/Initialization/SystemInitializerCommon.cpp
@@ -25,6 +25,8 @@
 #if defined(_WIN32)
 #include "Plugins/Process/Windows/Common/ProcessWindowsLog.h"
 #include "lldb/Host/windows/windows.h"
+// for _CrtSetReportMode
+#include 
 #endif
 
 #include "llvm/Support/TargetSelect.h"
Index: lldb/source/Host/windows/FileSystem.cpp
===
--- lldb/source/Host/windows/FileSystem.cpp
+++ lldb/source/Host/windows/FileSystem.cpp
@@ -12,6 +12,9 @@
 #include 
 #include 
 
+// For _SH_*
+#include 
+
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/windows/AutoHandle.h"
 #include "lldb/Host/windows/PosixApi.h"
Index: lldb/include/lldb/Host/windows/PosixApi.h
===
--- lldb/include/lldb/Host/windows/PosixApi.h
+++ lldb/include/lldb/Host/windows/PosixApi.h
@@ -45,6 +45,15 @@
 #define S_IRWXG 0
 #define S_IRWXO 0
 
+#ifdef __MINGW32__
+// pyconfig.h typedefs this.  We require python headers to be included before
+// any LLDB headers, but there's no way to prevent python's pid_t definition
+// from leaking, so this is the best option.
+#ifndef NO_PID_T
+#include 
+#endif
+#endif // __MINGW32__
+
 #ifdef _MSC_VER
 
 // PRIxxx format macros for printf()
@@ -80,6 +89,8 @@
 char *strcasestr(const char *s, const char *find);
 char *realpath(const char *name, char *resolved);
 
+#ifdef _MSC_VER
+
 int usleep(uint32_t useconds);
 char *basename(char *path);
 char *dirname(char *path);
@@ -87,6 +98,8 @@
 int strcasecmp(const char *s1, const char *s2);
 int strncasecmp(const char *s1, const char *s2, size_t n);
 
+#endif // _MSC_VER
+
 // empty functions
 inline int posix_openpt(int flag) { LLVM_BUILTIN_UNREACHABLE; }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65691: Various build fixes for lldb on MinGW

2019-08-02 Thread Martin Storsjö via Phabricator via lldb-commits

mstorsjo added a reviewer: zturner.
mstorsjo added a comment.

As context (I haven't followed lldb almost at all), what's the general status 
of lldb on windows - generally working, or still a work in progress? Does it 
work with dwarf debug info in COFF (as commonly used in mingw environments), in 
addition to PDB? I.e. is the existing dwarf support tied to the ELF/MachO 
formats, or is it decoupled?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65691/new/

https://reviews.llvm.org/D65691



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

47 matches

Mail list logo