[Lldb-commits] [lldb] r368975 - [lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module build failures

[Raphael Isemann via lldb-commits]

Author: teemperor
Date: Thu Aug 15 00:29:53 2019
New Revision: 368975

URL: http://llvm.org/viewvc/llvm-project?rev=368975&view=rev
Log:
[lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module build 
failures

Summary:
When building with modules we currently fail randomly to build LLDB's modules 
and get error messages like below:
```
In file included from :1:
In file included from llvm-project/llvm/include/llvm/IR/Argument.h:18:
llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 
'llvm/IR/Attributes.inc' file not found
#include "llvm/IR/Attributes.inc"
 ^~~~
...
In file included from 
llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:9:
llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.h:12:10: fatal error: 
could not build module 'lldb_Wrapper'
```

The reason for this is that our source files can include Clang headers which in 
turn include files like Attributes.inc which
are generated by intrinsics_gen. However, it seems Clang can't express this 
dependency in its CMake code, so intrinsics_gen
is actually not guaranteed to be built before we start parsing LLDB source 
files and Clang headers. Clang worked around this
by letting all libraries depend on intrinsics_gen, which at least lets their 
builds pass.

As I haven't figured out how to solve these dependencies properly and I want to 
get the LLDB+Modules build green,
I suggest we copy Clang's hack until we figure out how to get Clang's 
dependencies right.

Reviewers: sgraenitz, aprantl, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: mgorny, javed.absar, kristof.beyls, mgrang, lldb-commits

Tags: #lldb

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

Modified:
lldb/trunk/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=368975&r1=368974&r2=368975&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Thu Aug 15 00:29:53 2019
@@ -40,6 +40,15 @@ if (NOT LLDB_DISABLE_PYTHON)
   add_subdirectory(scripts)
 endif ()
 
+# We need the headers generated by instrinsics_gen before we can compile
+# any source file in LLDB as the imported Clang modules might include
+# some of these generated headers. This approach is copied from Clang's main
+# CMakeLists.txt, so it should kept in sync the code in Clang which was added
+# in llvm-svn 308844.
+if(LLVM_ENABLE_MODULES AND NOT LLDB_BUILT_STANDALONE)
+  list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
+endif()
+
 if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE)
   set(LLVM_USE_HOST_TOOLS ON)
   include(CrossCompile)


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

[Lldb-commits] [PATCH] D66208: [lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module build failures

[Raphael Isemann via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL368975: [lldb] Let LLDB depend on intrinsics_gen to fix 
non-deterministic module build… (authored by teemperor, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66208?vs=215070&id=215335#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66208

Files:
  lldb/trunk/CMakeLists.txt


Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -40,6 +40,15 @@
   add_subdirectory(scripts)
 endif ()
 
+# We need the headers generated by instrinsics_gen before we can compile
+# any source file in LLDB as the imported Clang modules might include
+# some of these generated headers. This approach is copied from Clang's main
+# CMakeLists.txt, so it should kept in sync the code in Clang which was added
+# in llvm-svn 308844.
+if(LLVM_ENABLE_MODULES AND NOT LLDB_BUILT_STANDALONE)
+  list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
+endif()
+
 if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE)
   set(LLVM_USE_HOST_TOOLS ON)
   include(CrossCompile)


Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -40,6 +40,15 @@
   add_subdirectory(scripts)
 endif ()
 
+# We need the headers generated by instrinsics_gen before we can compile
+# any source file in LLDB as the imported Clang modules might include
+# some of these generated headers. This approach is copied from Clang's main
+# CMakeLists.txt, so it should kept in sync the code in Clang which was added
+# in llvm-svn 308844.
+if(LLVM_ENABLE_MODULES AND NOT LLDB_BUILT_STANDALONE)
+  list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
+endif()
+
 if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_STANDALONE)
   set(LLVM_USE_HOST_TOOLS ON)
   include(CrossCompile)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D66174: [Utility] Reimplement RegularExpression on top of llvm::Regex

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I was unhappy with the `()` workaround, so I did some investigation. Now, I am 
even more unhappy, but at least better educated. :P

Basically, what I've learned is that according to POSIX 
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html an 
empty string is not a valid regular expression. Most tools seem to ignore that, 
and treat it as if it matches everything (and I can't say I blame them). 
However, the BSD implementation (that the llvm stuff is based on) tried to do a 
strict implementation and it rejects that as an invalid expression.

Funnily enough, `()` is not valid according to POSIX either, but the BSD 
implementation accepts it. So does (linux) grep and python. However, perl 
rejects it (it still considers it a valid expression, but one that doesn't 
match anything).

`a||b` (a OR empty pattern OR b) is also not valid. grep, python and perl 
accept that, but the BSD regexes don't.

So, overall, it seems to me that there is a lot of confusion about what should 
empty (sub-)patterns do. I don't think special-casing "" in 
lldb_private::RegularExpression would help alleviate any of that confusion as 
we would be still left with all of the other inconsistencies. So, if we want to 
go through with this (and I still think we should), I guess we'll just have to 
bite the bullet and say that our expressions are now (more or less) POSIX 
conformant, and repeat that to anyone who comes complaining that lldb regexes 
behave differently than grep, python or older versions of lldb...




Comment at: lldb/source/Commands/CommandObjectFrame.cpp:577-578
+  if (llvm::Error err = regex.GetError())
+result.GetErrorStream().Printf(
+"error: %s\n", llvm::toString(std::move(err)).c_str());
   else

`GetErrorStream().Format("error: {0}\n", llvm::fmt_consume(std::move(err)));` 
would be slightly less verbose.


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

https://reviews.llvm.org/D66174



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

[Lldb-commits] [PATCH] D66250: [JIT][Unwinder] Add Trampoline ObjectFile and UnwindPlan support for FCB

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I have one high-level question. Who is generating the code inside the 
"trampoline" object file? Couldn't we have him generate proper unwind 
information so that the regular unwind machinery "just works"? I imagine all it 
would take is a couple of well-placed `.cfi` assembler directives...




Comment at: lldb/source/Target/ABI.cpp:10
 #include "lldb/Target/ABI.h"
+#include "Plugins/ObjectFile/Trampoline/ObjectFileTrampoline.h"
+#include "lldb/Core/Module.h"

If this is going to be something that is called directly from core lldb code, 
then it not a "plugin" by any stretch of imagination. I think we should put 
this file some place else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66250



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

[Lldb-commits] [PATCH] D66249: [JIT][Breakpoint] Add "BreakpointInjectedSite" and FCB Trampoline

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I didn't go into all the details of this patch, as I am guessing this will 
still go through a number of revisions, but I did make a couple notes of things 
that caught my eye while glancing over it.




Comment at: lldb/include/lldb/Breakpoint/BreakpointInjectedSite.h:50
+class BreakpointInjectedSite
+: public std::enable_shared_from_this,
+  public BreakpointSite {

BreakpointSite is already shared_ptr-enabled. Why this? I don't think that's 
how you're supposed to use this class.



Comment at: lldb/include/lldb/Breakpoint/BreakpointSite.h:54-56
+   static bool classof(const BreakpointSite *bp_site) {
+ return bp_site->getKind() == eKindBreakpointSite;
+   }

This is weird. So, in OO terminology, `BreakpointInjectedSite` "is-a" 
`BreakpointSite`, but if you ask `llvm::isa(injected_site)`, it 
will return false?



Comment at: lldb/include/lldb/Expression/ExpressionVariable.h:210
+public:
+  typedef AdaptedIterable

What is the purpose of this `AdaptedIterable`, and why is it better than just 
returning  say `ArrayRefhttp://llvm.org/docs/ProgrammersManual.html#formatting-strings-the-formatv-function>,
 and the specifics are generally next to the definition of the actual format 
provider (e.g. 
).
 I find it very helpful to look at their unit tests too: 
.



Comment at: lldb/source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h:96-98
+  uint64_t GetJumpOpcode() override { return X64_JMP_OPCODE; }
+
+  size_t GetJumpSize() override { return X64_JMP_SIZE; }

replace with `ArrayRef GetJumpOpcode();` or something similar.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66249



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

[Lldb-commits] [lldb] r369000 - [lldb][NFC] Refactor remaining completion logic to use CompletionRequests

[Raphael Isemann via lldb-commits]

Author: teemperor
Date: Thu Aug 15 06:14:10 2019
New Revision: 369000

URL: http://llvm.org/viewvc/llvm-project?rev=369000&view=rev
Log:
[lldb][NFC] Refactor remaining completion logic to use CompletionRequests

This patch moves the remaining completion functions from the
old completion API (that used several variables) to just
passing a single CompletionRequest.

This is for the most part a simple change as we just replace
the old arguments with a single CompletionRequest argument.

There are a few places where I had to create new CompletionRequests
in the called functions as CompletionRequests itself are immutable
and don't expose their internal match list anymore. This means that
if a function wanted to change the CompletionRequest or directly
access the result list, we need to work around this by creating
a new CompletionRequest and a temporary match/description list.

Preparation work for rdar://53769355

Modified:
lldb/trunk/include/lldb/Core/IOHandler.h
lldb/trunk/include/lldb/Expression/REPL.h
lldb/trunk/include/lldb/Host/Editline.h
lldb/trunk/include/lldb/Interpreter/CommandInterpreter.h
lldb/trunk/include/lldb/Utility/CompletionRequest.h
lldb/trunk/source/API/SBCommandInterpreter.cpp
lldb/trunk/source/Core/IOHandler.cpp
lldb/trunk/source/Expression/REPL.cpp
lldb/trunk/source/Host/common/Editline.cpp
lldb/trunk/source/Interpreter/CommandInterpreter.cpp

Modified: lldb/trunk/include/lldb/Core/IOHandler.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/IOHandler.h?rev=369000&r1=368999&r2=369000&view=diff
==
--- lldb/trunk/include/lldb/Core/IOHandler.h (original)
+++ lldb/trunk/include/lldb/Core/IOHandler.h Thu Aug 15 06:14:10 2019
@@ -10,6 +10,7 @@
 #define liblldb_IOHandler_h_
 
 #include "lldb/Core/ValueObjectList.h"
+#include "lldb/Utility/CompletionRequest.h"
 #include "lldb/Utility/ConstString.h"
 #include "lldb/Utility/Flags.h"
 #include "lldb/Utility/Predicate.h"
@@ -198,9 +199,8 @@ public:
 
   virtual void IOHandlerDeactivated(IOHandler &io_handler) {}
 
-  virtual int IOHandlerComplete(IOHandler &io_handler, const char 
*current_line,
-const char *cursor, const char *last_char,
-StringList &matches, StringList &descriptions);
+  virtual int IOHandlerComplete(IOHandler &io_handler,
+CompletionRequest &request);
 
   virtual const char *IOHandlerGetFixIndentationCharacters() { return nullptr; 
}
 
@@ -414,10 +414,7 @@ private:
   static int FixIndentationCallback(Editline *editline, const StringList 
&lines,
 int cursor_position, void *baton);
 
-  static int AutoCompleteCallback(const char *current_line, const char *cursor,
-  const char *last_char,
-  StringList &matches, StringList 
&descriptions,
-  void *baton);
+  static int AutoCompleteCallback(CompletionRequest &request, void *baton);
 #endif
 
 protected:
@@ -448,9 +445,8 @@ public:
 
   bool GetResponse() const { return m_user_response; }
 
-  int IOHandlerComplete(IOHandler &io_handler, const char *current_line,
-const char *cursor, const char *last_char,
-StringList &matches, StringList &descriptions) 
override;
+  int IOHandlerComplete(IOHandler &io_handler,
+CompletionRequest &request) override;
 
   void IOHandlerInputComplete(IOHandler &io_handler,
   std::string &data) override;

Modified: lldb/trunk/include/lldb/Expression/REPL.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/REPL.h?rev=369000&r1=368999&r2=369000&view=diff
==
--- lldb/trunk/include/lldb/Expression/REPL.h (original)
+++ lldb/trunk/include/lldb/Expression/REPL.h Thu Aug 15 06:14:10 2019
@@ -103,9 +103,8 @@ public:
   void IOHandlerInputComplete(IOHandler &io_handler,
   std::string &line) override;
 
-  int IOHandlerComplete(IOHandler &io_handler, const char *current_line,
-const char *cursor, const char *last_char,
-StringList &matches, StringList &descriptions) 
override;
+  int IOHandlerComplete(IOHandler &io_handler,
+CompletionRequest &request) override;
 
 protected:
   static int CalculateActualIndentation(const StringList &lines);

Modified: lldb/trunk/include/lldb/Host/Editline.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/Editline.h?rev=369000&r1=368999&r2=369000&view=diff
==
--- lldb/trunk/include/lldb/Host/Editline.h (original)
+++ lldb/trunk/include/lldb/Host/Editline.h Thu Aug 15 06:1

[Lldb-commits] [PATCH] D66241: stop-hooks don't fire on "step-out"

[Greg Clayton via Phabricator via lldb-commits]

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

Better. Might be good to put a comment inside CalculatePublicStopInfo() 
regarding why the "SetStopInfo(GetStopInfo());" is needed. Seems like you could 
just remove the code from the sight of it. I will leave that up to you though.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D66241



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

[Lldb-commits] [PATCH] D66174: [Utility] Reimplement RegularExpression on top of llvm::Regex

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D66174#1631055 , @labath wrote:

> I was unhappy with the `()` workaround, so I did some investigation. Now, I 
> am even more unhappy, but at least better educated. :P
>
> Basically, what I've learned is that according to POSIX 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html an 
> empty string is not a valid regular expression. Most tools seem to ignore 
> that, and treat it as if it matches everything (and I can't say I blame 
> them). However, the BSD implementation (that the llvm stuff is based on) 
> tried to do a strict implementation and it rejects that as an invalid 
> expression.
>
> Funnily enough, `()` is not valid according to POSIX either, but the BSD 
> implementation accepts it. So does (linux) grep and python. However, perl 
> rejects it (it still considers it a valid expression, but one that doesn't 
> match anything).
>
> `a||b` (a OR empty pattern OR b) is also not valid. grep, python and perl 
> accept that, but the BSD regexes don't.
>
> So, overall, it seems to me that there is a lot of confusion about what 
> should empty (sub-)patterns do. I don't think special-casing "" in 
> lldb_private::RegularExpression would help alleviate any of that confusion as 
> we would be still left with all of the other inconsistencies. So, if we want 
> to go through with this (and I still think we should), I guess we'll just 
> have to bite the bullet and say that our expressions are now (more or less) 
> POSIX conformant, and repeat that to anyone who comes complaining that lldb 
> regexes behave differently than grep, python or older versions of lldb...


For the record, in case my earlier response gets lost in the inline comments, I 
strongly support this :-)


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

https://reviews.llvm.org/D66174



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

[Lldb-commits] [PATCH] D66248: [JIT][Command] Add "inject-condition" flag to conditional breakpoints

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik added inline comments.



Comment at: lldb/include/lldb/Breakpoint/BreakpointOptions.h:120
+  ///
   BreakpointOptions(const char *condition, bool enabled = true,
 int32_t ignore = 0, bool one_shot = false,

You have a lot of `bool` parameters, these are hard to distinguish when calling 
the function and easy to get mixed up during refactors and subsequent merge 
conflicts. It would probably be better to combine these `bool` options into a 
`struct` and then each option has an explicit name that that will be assigned 
to which makes it explicit which options are being chosen at the call site.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/fast_conditional_breakpoints/main.c:14
+
+#define asm __asm__
+

I don't think we need this macro.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/fast_conditional_breakpoints/main.c:30
+printf("local_count = %d\n", local_count++);  // Find the line number of 
condition breakpoint for local_count
+asm("nop");
+asm("nop");

Can you explain why we need the `nop`s injected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66248



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

[Lldb-commits] [lldb] r369034 - Change test to use uint64_t to support compiling for 32-bit architectures.

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Thu Aug 15 11:37:11 2019
New Revision: 369034

URL: http://llvm.org/viewvc/llvm-project?rev=369034&view=rev
Log:
Change test to use uint64_t to support compiling for 32-bit architectures.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c?rev=369034&r1=369033&r2=369034&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c Thu Aug 
15 11:37:11 2019
@@ -91,8 +91,8 @@ int main (int argc, char const *argv[])
 packed.c = 0x7112233;
 
 struct LargePackedBits {
-unsigned long a: 36;
-unsigned long b: 36;
+uint64_t a: 36;
+uint64_t b: 36;
 } __attribute__((packed));
 
 struct LargePackedBits large_packed =


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

[Lldb-commits] [PATCH] D66241: stop-hooks don't fire on "step-out"

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

In D66241#1631426 , @clayborg wrote:

> Better. Might be good to put a comment inside CalculatePublicStopInfo() 
> regarding why the "SetStopInfo(GetStopInfo());" is needed. Seems like you 
> could just remove the code from the sight of it. I will leave that up to you 
> though.


The thing you have to understand for this to make sense is that what you get 
from GetStopInfo depends on when you ask the question.  If you have just 
stopped, but haven't gone through the ShouldStop mechanism, then there are no 
completed plans, and you get the raw stop info.  But if you ask again after 
we've done "ShouldStop", then we're in a position to attribute the stop to the 
plan that was managing it.  That's why I said explicitly you had to do 
CalculatePublicStopInfo after ShouldStop.

I can refine the comment a bit to make this clearer.

I think this is going to be a little opaque so long as we aren't making a real 
distinction between the private (what I used to call the actual stop info - 
there's even a few comments that still reference this...) and the public stop 
info.

There's the added complication that sometimes you need to rewind to an old stop 
reason.  For instance, you finish a step out, then run a function.  Now the 
actual stop info is the breakpoint stop at the entry point that caught the end 
of the expression evaluation.  The public stop info is "Completed Function 
Thread Plan".  But showing that would be confusing, users don't care that a 
function was run, particularly if it was one they didn't directly cause.  The 
stop info you actually want to show users is still  "Completed step out plan".

These complexities are overlaid on one stop info, and a bunch of stop_id 
variables.  We also rely on the assumption that you can always re-fetch the 
private stop info with the plugin-implemented CalculateStopInfo call.  But you 
have to be careful, because though you can rewind to an old Public StopInfo, 
you can't get back to the actual StopInfo that caused it - since the process 
has moved on.   This requires other bits of fancy footwork.

This all needs to be teased apart and better represented.  But that's a task 
for another day.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D66241



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

[Lldb-commits] [lldb] r369052 - Stop-hooks weren't getting called on step-out. Fix that.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Aug 15 14:37:52 2019
New Revision: 369052

URL: http://llvm.org/viewvc/llvm-project?rev=369052&view=rev
Log:
Stop-hooks weren't getting called on step-out. Fix that.

There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so that the
next call to GetStopInfo would replace it with the StopInfoThreadPlan.

But the stop-hooks check for whether a thread stopped for a reason didn't
trigger this conversion.  So I added an API to do that directly, and then
called it where before we just reset the StopInfo.



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

Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/

lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/main.c
Modified:
lldb/trunk/include/lldb/Target/Thread.h
lldb/trunk/source/Target/StopInfo.cpp
lldb/trunk/source/Target/Thread.cpp

Modified: lldb/trunk/include/lldb/Target/Thread.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Thread.h?rev=369052&r1=369051&r2=369052&view=diff
==
--- lldb/trunk/include/lldb/Target/Thread.h (original)
+++ lldb/trunk/include/lldb/Target/Thread.h Thu Aug 15 14:37:52 2019
@@ -1101,6 +1101,17 @@ public:
   // right even if you have not calculated this yourself, or if it disagrees
   // with what you might have calculated.
   virtual lldb::StopInfoSP GetPrivateStopInfo();
+  
+  // Calculate the stop info that will be shown to lldb clients.  For instance,
+  // a "step out" is implemented by running to a breakpoint on the function 
+  // return PC, so the process plugin initially sets the stop info to a
+  // StopInfoBreakpoint. But once we've run the ShouldStop machinery, we
+  // discover that there's a completed ThreadPlanStepOut, and that's really
+  // the StopInfo we want to show.  That will happen naturally the next
+  // time GetStopInfo is called, but if you want to force the replacement,
+  // you can call this.
+
+  void CalculatePublicStopInfo();
 
   // Ask the thread subclass to set its stop info.
   //

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile?rev=369052&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile 
(added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile 
Thu Aug 15 14:37:52 2019
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+CFLAGS_EXTRAS += -std=c99
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py?rev=369052&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
 Thu Aug 15 14:37:52 2019
@@ -0,0 +1,45 @@
+"""
+Test that stop hooks trigger on "step-out"
+"""
+
+from __future__ import print_function
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class TestStopHooks(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+# If your test case doesn't stress debug info, the
+# set this to true.  That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_stop_hooks_step_out(self):
+"""Test that stop hooks fire on step-out."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.step_out_test()
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+def step_out_test(self):
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   "Set a breakpoint here", 
self.main_source_file)
+
+interp = self.dbg.GetCommandInterpreter()
+result = lldb.SBCommandReturnObject()
+interp.HandleCommand("target stop-hook add -o 'expr g_var++'", result)
+self.assertTrue(result.Succeeded, "Set the target stop hook")
+thread.StepOut()
+var = target.FindFirstGlobalVariable("g_var")
+self.assertTrue(var.IsValid())
+self.assertEqual(var.GetValueAsUnsigned(), 1, "Updated g_var")
+
+

Added: 
lldb/trunk/packages

[Lldb-commits] [PATCH] D66241: stop-hooks don't fire on "step-out"

[Jim Ingham via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL369052: Stop-hooks weren't getting called on step-out. 
Fix that. (authored by jingham, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66241?vs=215280&id=215470#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66241

Files:
  lldb/trunk/include/lldb/Target/Thread.h
  lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
  lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/main.c
  lldb/trunk/source/Target/StopInfo.cpp
  lldb/trunk/source/Target/Thread.cpp

Index: lldb/trunk/include/lldb/Target/Thread.h
===
--- lldb/trunk/include/lldb/Target/Thread.h
+++ lldb/trunk/include/lldb/Target/Thread.h
@@ -1101,6 +1101,17 @@
   // right even if you have not calculated this yourself, or if it disagrees
   // with what you might have calculated.
   virtual lldb::StopInfoSP GetPrivateStopInfo();
+  
+  // Calculate the stop info that will be shown to lldb clients.  For instance,
+  // a "step out" is implemented by running to a breakpoint on the function 
+  // return PC, so the process plugin initially sets the stop info to a
+  // StopInfoBreakpoint. But once we've run the ShouldStop machinery, we
+  // discover that there's a completed ThreadPlanStepOut, and that's really
+  // the StopInfo we want to show.  That will happen naturally the next
+  // time GetStopInfo is called, but if you want to force the replacement,
+  // you can call this.
+
+  void CalculatePublicStopInfo();
 
   // Ask the thread subclass to set its stop info.
   //
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/TestStopHooks.py
@@ -0,0 +1,45 @@
+"""
+Test that stop hooks trigger on "step-out"
+"""
+
+from __future__ import print_function
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class TestStopHooks(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+# If your test case doesn't stress debug info, the
+# set this to true.  That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_stop_hooks_step_out(self):
+"""Test that stop hooks fire on step-out."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.step_out_test()
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+def step_out_test(self):
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(self,
+   "Set a breakpoint here", self.main_source_file)
+
+interp = self.dbg.GetCommandInterpreter()
+result = lldb.SBCommandReturnObject()
+interp.HandleCommand("target stop-hook add -o 'expr g_var++'", result)
+self.assertTrue(result.Succeeded, "Set the target stop hook")
+thread.StepOut()
+var = target.FindFirstGlobalVariable("g_var")
+self.assertTrue(var.IsValid())
+self.assertEqual(var.GetValueAsUnsigned(), 1, "Updated g_var")
+
+
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+CFLAGS_EXTRAS += -std=c99
+
+include $(LEVEL)/Makefile.rules
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/stop-hooks/main.c
@@ -0,0 +1,14 @@
+#include 
+
+static int g_var = 0;
+
+int step_out_of_me()
+{
+  return g_var; // Set a breakpoint here and step out.
+}
+
+int
+main()
+{
+  return step_out_of_me();
+}
Index: lldb/trunk/source/Target/StopInfo.cpp
===
--- lldb/trunk/source/Target/StopInfo.cpp
+++ lldb/trunk/source/Target/StopInfo.cpp
@@ -543,10 +543,10 @@
 // additionally to the breakpoint
 m_should_stop = true;
 
-// Here we clean the preset stop info so the next GetStopInfo call will
-/

[Lldb-commits] [PATCH] D66250: [JIT][Unwinder] Add Trampoline ObjectFile and UnwindPlan support for FCB

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D66250#1631200 , @labath wrote:

> I have one high-level question. Who is generating the code inside the 
> "trampoline" object file? Couldn't we have him generate proper unwind 
> information so that the regular unwind machinery "just works"? I imagine all 
> it would take is a couple of well-placed `.cfi` assembler directives...


The ABI plugin creates the trampoline by writing bytes directly IIRC.  The 
trampoline has to save the entire register context to the stack before it calls 
the jitted function that does the comparison and possibly breaks.  Then the 
trampoline restores all the register context, executes any replaced functions, 
and then jumps directly back into the original function.

The trampoline has to be expressed in terms of assembly (or hardcoded bytes) 
because we're not using the normal calling conventions - we have to spill all 
registers so the jitted function doesn't overwrite a caller-spilled register 
and corrupt the original user function that we're patching in to.  Also, it is 
not CALLed from the original user function, it is JMPed to, so there's no way 
for the unwinder to get from the trampoline function back to the original user 
function by looking at the stack.

The question is then, why do we have to JMP to the trampoline?  This simplifies 
running the replaced instructions in the trampoline, because the stack pointer 
and frame pointer have the original user function's values when the replaced 
instructions are executed at the end of the trampoline.  Using a CALL to get 
from the original function to the trampoline solves the unwinder problem, but 
we're still going to need to express the trampoline in assembly terms to save & 
restore all the registers, and have the replaced instructions execute.

On non-x86 architectures, like Aarch64, doing a function call to the trampoline 
would mean we need to spill the $lr value to the stack in the original user 
function before calling the trampoline so we don't overwrite the value; that's 
a larger number of instructions that need to be shifted into the trampoline to 
execute.

Of course the only reason we have this ObjectFile plugin is for the unwinder's 
benefit.  If we used a CALL instruction to get to the trampoline, and we sent 
the assembly through the clang FE as a series of asm()s to jit it, instead of 
writing the bytes down, the unwinder would get the unwind information as we do 
a normal jitted function -- you're right, cfi directives to point to the saved 
register context would be sufficient.

But because we're jumping directly to the trampoline, and jumping back from the 
trampoline, we need to have a hand-written unwind plan that has the return 
address hard coded in it for the unwinder to work.

Is having a small ObjectFile plugin for this purpose a bad idea?  It seems like 
the right approach, but maybe I'm not seeing the issue.  The CreateInstance 
method returns false always, so when we iterate looking for an ObjectFile 
plugin, we will call this method but it will return false right away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66250



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

[Lldb-commits] [lldb] r369072 - [DebugLine] Don't try to guess the path style

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu Aug 15 16:53:15 2019
New Revision: 369072

URL: http://llvm.org/viewvc/llvm-project?rev=369072&view=rev
Log:
[DebugLine] Don't try to guess the path style

In r368879 I made an attempt to guess the path style from the files in
the line table. After some consideration I now think this is a poor
idea. This patch undoes that behavior and instead adds an optional
argument to specify the path style. This allows us to make that decision
elsewhere where we have more information. In case of LLDB based on the
Unit.

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

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=369072&r1=369071&r2=369072&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Thu Aug 15 
16:53:15 2019
@@ -178,11 +178,10 @@ ParseLLVMLineTable(lldb_private::DWARFCo
   return *line_table;
 }
 
-static FileSpecList
-ParseSupportFilesFromPrologue(const lldb::ModuleSP &module,
-  const llvm::DWARFDebugLine::Prologue &prologue,
-  llvm::StringRef compile_dir = {},
-  FileSpec first_file = {}) {
+static FileSpecList ParseSupportFilesFromPrologue(
+const lldb::ModuleSP &module,
+const llvm::DWARFDebugLine::Prologue &prologue, FileSpec::Style style,
+llvm::StringRef compile_dir = {}, FileSpec first_file = {}) {
   FileSpecList support_files;
   support_files.Append(first_file);
 
@@ -191,8 +190,8 @@ ParseSupportFilesFromPrologue(const lldb
 std::string original_file;
 if (!prologue.getFileNameByIndex(
 idx, compile_dir,
-llvm::DILineInfoSpecifier::FileLineInfoKind::Default,
-original_file)) {
+llvm::DILineInfoSpecifier::FileLineInfoKind::Default, 
original_file,
+style)) {
   // Always add an entry so the indexes remain correct.
   support_files.EmplaceBack();
   continue;
@@ -202,18 +201,14 @@ ParseSupportFilesFromPrologue(const lldb
 if (!prologue.getFileNameByIndex(
 idx, compile_dir,
 llvm::DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath,
-remapped_file)) {
+remapped_file, style)) {
   // Always add an entry so the indexes remain correct.
-  support_files.EmplaceBack(original_file,
-FileSpec::GuessPathStyle(original_file)
-.getValueOr(FileSpec::Style::native));
+  support_files.EmplaceBack(original_file, style);
   continue;
 }
 
 module->RemapSourceFile(llvm::StringRef(original_file), remapped_file);
-support_files.EmplaceBack(remapped_file,
-  FileSpec::GuessPathStyle(remapped_file)
-  .getValueOr(FileSpec::Style::native));
+support_files.EmplaceBack(remapped_file, style);
   }
 
   return support_files;
@@ -893,8 +888,8 @@ SymbolFileDWARF::GetTypeUnitSupportFiles
  "SymbolFileDWARF::GetTypeUnitSupportFiles failed to parse 
"
  "the line table prologue");
 } else {
-  list =
-  ParseSupportFilesFromPrologue(GetObjectFile()->GetModule(), 
prologue);
+  list = ParseSupportFilesFromPrologue(GetObjectFile()->GetModule(),
+   prologue, tu.GetPathStyle());
 }
   }
   return list;
@@ -1013,7 +1008,7 @@ bool SymbolFileDWARF::ParseLineTable(Com
   }
 
   comp_unit.SetSupportFiles(ParseSupportFilesFromPrologue(
-  comp_unit.GetModule(), line_table->Prologue,
+  comp_unit.GetModule(), line_table->Prologue, dwarf_cu->GetPathStyle(),
   dwarf_cu->GetCompilationDirectory().GetCString(), FileSpec(comp_unit)));
 
   return true;


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

[Lldb-commits] [PATCH] D66327: [dotest] Make it possible to forward CCC_OVERRIDE_OPTIONS to Make

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added reviewers: labath, aprantl, davide.
Herald added a project: LLDB.

Setting `CCC_OVERRIDE_OPTIONS ` is a powerful way to change the behavior of the 
compiler. It's especially convenient for modifying how we build test inferiors. 
However, this is currently not possible, because we don't forward the 
environment variable. This patch adds support for this.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D66327

Files:
  lldb/packages/Python/lldbsuite/test/plugins/builder_base.py


Index: lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
===
--- lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
+++ lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
@@ -36,6 +36,16 @@
 return os.path.realpath(compiler)
 
 
+def getEnv():
+"""Returns the build environment."""
+env = dict()
+whitelist = ['PATH', 'CCC_OVERRIDE_OPTIONS']
+for v in whitelist:
+if v in os.environ:
+env[v] = os.environ[v]
+return env
+
+
 def getArchFlag():
 """Returns the flag required to specify the arch"""
 compiler = getCompiler()
@@ -127,7 +137,7 @@
 
 def runBuildCommands(commands, sender):
 try:
-lldbtest.system(commands, sender=sender)
+lldbtest.system(commands, sender=sender, env=os.environ.copy())
 except subprocess.CalledProcessError as called_process_error:
 # Convert to a build-specific error.
 # We don't do that in lldbtest.system() since that


Index: lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
===
--- lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
+++ lldb/packages/Python/lldbsuite/test/plugins/builder_base.py
@@ -36,6 +36,16 @@
 return os.path.realpath(compiler)
 
 
+def getEnv():
+"""Returns the build environment."""
+env = dict()
+whitelist = ['PATH', 'CCC_OVERRIDE_OPTIONS']
+for v in whitelist:
+if v in os.environ:
+env[v] = os.environ[v]
+return env
+
+
 def getArchFlag():
 """Returns the flag required to specify the arch"""
 compiler = getCompiler()
@@ -127,7 +137,7 @@
 
 def runBuildCommands(commands, sender):
 try:
-lldbtest.system(commands, sender=sender)
+lldbtest.system(commands, sender=sender, env=os.environ.copy())
 except subprocess.CalledProcessError as called_process_error:
 # Convert to a build-specific error.
 # We don't do that in lldbtest.system() since that
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D66331: Save / restore selected platform in tests that may change it

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a reviewer: labath.
Herald added a subscriber: abidh.
Herald added a project: LLDB.

Running the testsuite against an iOS device, it seems like I can lose the 
remote platform when certain tests run (and running in single-threaded mode aka 
no-multiprocess mode).  Attached is a patch to use the setUp/tearDown test 
class methods to save/restore the platform.

I'm not sure if fixing this on a test-by-test basis is the right place for it.  
It might be better to have dotest.py's run_suite() save the remote platform and 
lldbtest.py's class Base setUpClass() method re-set the platform before the 
test is invoked, in case it was mutated during a test run.

Pavel, what do you think about this?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D66331

Files:
  
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestWriteMemory.py
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
  
packages/Python/lldbsuite/test/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py


Index: 
packages/Python/lldbsuite/test/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
===
--- 
packages/Python/lldbsuite/test/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
+++ 
packages/Python/lldbsuite/test/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
@@ -11,6 +11,14 @@
 class TestPlatformProcessConnect(gdbremote_testcase.GdbRemoteTestCaseBase):
 mydir = TestBase.compute_mydir(__file__)
 
+def setUp(self):
+super(TestPlatformProcessConnect, self).setUp()
+self._initial_platform = lldb.DBG.GetSelectedPlatform()
+
+def tearDown(self):
+lldb.DBG.SetSelectedPlatform(self._initial_platform)
+super(TestPlatformProcessConnect, self).tearDown()
+
 @llgs_test
 @no_debug_info_test
 @skipIf(remote=False)
Index: 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
===
--- 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
+++ 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
@@ -15,8 +15,15 @@
 NO_DEBUG_INFO_TESTCASE = True
 
 mydir = TestBase.compute_mydir(__file__)
-_initial_platform = lldb.DBG.GetSelectedPlatform()
 
+def setUp(self):
+super(LinuxCoreThreadsTestCase, self).setUp()
+self._initial_platform = lldb.DBG.GetSelectedPlatform()
+
+def tearDown(self):
+lldb.DBG.SetSelectedPlatform(self._initial_platform)
+super(LinuxCoreThreadsTestCase, self).tearDown()
+
 _i386_pid = 5193
 _x86_64_pid = 5222
 
@@ -56,4 +63,3 @@
 self.assertEqual(signal, 0)
 
 self.dbg.DeleteTarget(target)
-lldb.DBG.SetSelectedPlatform(self._initial_platform)
Index: 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
===
--- 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
+++ 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
@@ -15,8 +15,14 @@
 NO_DEBUG_INFO_TESTCASE = True
 
 mydir = TestBase.compute_mydir(__file__)
-_initial_platform = lldb.DBG.GetSelectedPlatform()
+def setUp(self):
+super(GCoreTestCase, self).setUp()
+self._initial_platform = lldb.DBG.GetSelectedPlatform()
 
+def tearDown(self):
+lldb.DBG.SetSelectedPlatform(self._initial_platform)
+super(GCoreTestCase, self).tearDown()
+
 _i386_pid = 5586
 _x86_64_pid = 5669
 
@@ -47,4 +53,3 @@
 self.assertEqual(signal, 19)
 
 self.dbg.DeleteTarget(target)
-lldb.DBG.SetSelectedPlatform(self._initial_platform)
Index: 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestWriteMemory.py
===
--- 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestWriteMemory.py
+++ 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestWriteMemory.py
@@ -13,6 +13,14 @@
 def setBreakpoint(self, packet):
 return "OK"
 
+def setUp(self):
+super(TestWriteMemory, self).setUp()
+self._initial_platform = lldb.DBG.GetSelectedPlatform()
+
+def tearDown(self):
+lldb.DBG.SetSelectedPlatform(self._initial_platform)
+super(TestWriteMemory, self).tearDown()
+
 self.server.responder = MyResponder()
 target = self.dbg.CreateTargetWithFileAndTargetTriple('', 
'x86_64-pc-lin

[Lldb-commits] [lldb] r369083 - [lldb-server] Disable a test on Windows until it can be fixed

[Aaron Smith via lldb-commits]

Author: asmith
Date: Thu Aug 15 20:49:41 2019
New Revision: 369083

URL: http://llvm.org/viewvc/llvm-project?rev=369083&view=rev
Log:
[lldb-server] Disable a test on Windows until it can be fixed

Modified:
lldb/trunk/unittests/tools/lldb-server/tests/LLGSTest.cpp

Modified: lldb/trunk/unittests/tools/lldb-server/tests/LLGSTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/tools/lldb-server/tests/LLGSTest.cpp?rev=369083&r1=369082&r2=369083&view=diff
==
--- lldb/trunk/unittests/tools/lldb-server/tests/LLGSTest.cpp (original)
+++ lldb/trunk/unittests/tools/lldb-server/tests/LLGSTest.cpp Thu Aug 15 
20:49:41 2019
@@ -18,6 +18,9 @@ using namespace llvm;
 #undef SendMessage
 #endif
 
+// Disable this test on Windows as it appears to have a race condition
+// that causes lldb-server not to exit after the inferior hangs up.
+#if !defined(_WIN32)
 TEST_F(TestBase, LaunchModePreservesEnvironment) {
   putenv(const_cast("LLDB_TEST_MAGIC_VARIABLE=LLDB_TEST_MAGIC_VALUE"));
 
@@ -32,6 +35,7 @@ TEST_F(TestBase, LaunchModePreservesEnvi
   HasValue(testing::Property(&StopReply::getKind,
  WaitStatus{WaitStatus::Exit, 0})));
 }
+#endif
 
 TEST_F(TestBase, DS_TEST(DebugserverEnv)) {
   // Test that --env takes precedence over inherited environment variables.


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