[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

[Dávid Bolvanský via Phabricator via lldb-commits]

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

assert fix looks fine


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255



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

[Lldb-commits] [PATCH] D52461: [PDB] Introduce `PDBNameParser`

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a subscriber: labath.
aleksandr.urakov added a comment.

Hello!

I just have tried to patch `CPlusPlusNameParser` in the way to support MSVC 
demangled names, but there is a problem. `CPlusPlusNameParser` splits an 
incoming name in tokens with `clang::Lexer`. I've lexed the next name:

  `anonymous namespace'::foo

The lexer treats the first character (a grave accent) as an unknown token, and 
it's ok for our purposes. Then it sees an identifier (`anonymous`), a keyword 
(`namespace`), and it's ok too. But the problem is with the last part of the 
string. The lexer sees an apostrophe and supposes that it's a character 
constant, it looks for a closing apostrophe, don't find it and treats all the 
line ending (`'::foo`) as a single unknown token.

It is possible to somehow make `clang::Lexer` lex MSVC demangled names 
correctly, but I'm not sure if it is the right place to do it. And it may have 
then some side effects during lexing a real code.

Another option is to somehow preprocess the name before lexing and replace all 
//paired// apostrophes with grave accents, and after lexing replace with 
apostrophes back, and make `CPlusPlusNameParser` understand unknown grave 
accent tokens. But it's a bit tricky, may be you can suggest some better 
solution?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D52461



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

[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

Out of curiosity: why do we allow for both an empty array and an empty children 
sentinel? Is that distinction useful?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255



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

[Lldb-commits] [PATCH] D52461: [PDB] Introduce `PDBNameParser`

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D52461#1265335, @aleksandr.urakov wrote:

> Hello!
>
> I just have tried to patch `CPlusPlusNameParser` in the way to support MSVC 
> demangled names, but there is a problem. `CPlusPlusNameParser` splits an 
> incoming name in tokens with `clang::Lexer`. I've lexed the next name:
>
>   `anonymous namespace'::foo
>
>
> The lexer treats the first character (a grave accent) as an unknown token, 
> and it's ok for our purposes. Then it sees an identifier (`anonymous`), a 
> keyword (`namespace`), and it's ok too. But the problem is with the last part 
> of the string. The lexer sees an apostrophe and supposes that it's a 
> character constant, it looks for a closing apostrophe, don't find it and 
> treats all the line ending (`'::foo`) as a single unknown token.
>
> It is possible to somehow make `clang::Lexer` lex MSVC demangled names 
> correctly, but I'm not sure if it is the right place to do it. And it may 
> have then some side effects during lexing a real code.
>
> Another option is to somehow preprocess the name before lexing and replace 
> all //paired// apostrophes with grave accents, and after lexing replace with 
> apostrophes back, and make `CPlusPlusNameParser` understand unknown grave 
> accent tokens. But it's a bit tricky, may be you can suggest some better 
> solution?


Just handle the `anonymous namespace' thing specially before passing to 
`CPlusPlusNameParser`.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D52461



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

[Lldb-commits] [PATCH] D53090: [Windows] Fix a bug that causes lldb to freeze

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Do we have a test for this? It sounds like it shouldn't be hard to replicate 
the dependent library load failure in a test...


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53090



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

[Lldb-commits] [PATCH] D53226: [lldbsuite] Disable Test128BitsInteger on Windows

[Stella Stamenova via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB344543: [lldbsuite] Disable Test128BitsInteger on Windows 
(authored by stella.stamenova, committed by ).

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53226

Files:
  
packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py


Index: 
packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
===
--- 
packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
+++ 
packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
@@ -1,4 +1,7 @@
 from lldbsuite.test import lldbinline
 from lldbsuite.test import decorators
 
-lldbinline.MakeInlineTest(__file__, globals(), None)
+lldbinline.MakeInlineTest(
+__file__, globals(), [
+decorators.expectedFailureAll(
+oslist=["windows"], bugnumber="llvm.org/pr37656")])


Index: packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
===
--- packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
+++ packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
@@ -1,4 +1,7 @@
 from lldbsuite.test import lldbinline
 from lldbsuite.test import decorators
 
-lldbinline.MakeInlineTest(__file__, globals(), None)
+lldbinline.MakeInlineTest(
+__file__, globals(), [
+decorators.expectedFailureAll(
+oslist=["windows"], bugnumber="llvm.org/pr37656")])
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r344543 - [lldbsuite] Disable Test128BitsInteger on Windows

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Mon Oct 15 11:51:28 2018
New Revision: 344543

URL: http://llvm.org/viewvc/llvm-project?rev=344543&view=rev
Log:
[lldbsuite] Disable Test128BitsInteger on Windows

Summary: This test is failing on Windows because lldb does not support JIT on 
Windows.

Reviewers: davide, asmith

Reviewed By: davide

Subscribers: lldb-commits

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py?rev=344543&r1=344542&r2=344543&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
 Mon Oct 15 11:51:28 2018
@@ -1,4 +1,7 @@
 from lldbsuite.test import lldbinline
 from lldbsuite.test import decorators
 
-lldbinline.MakeInlineTest(__file__, globals(), None)
+lldbinline.MakeInlineTest(
+__file__, globals(), [
+decorators.expectedFailureAll(
+oslist=["windows"], bugnumber="llvm.org/pr37656")])


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

[Lldb-commits] [PATCH] D53297: [lldbsuite] Make the names of test classes unique

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova created this revision.
stella.stamenova added reviewers: jasonmolenda, asmith.
Herald added subscribers: lldb-commits, kbarton, nemanjai.

If the names are not unique, the tests overwrite each other's results and logs. 
This also causes failures on platforms where the files are locked for writing.

The names of the class/test pairs *have to* always be unique. The easiest way 
to achieve that is to name each class differently (usually the same as the file 
name).


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53297

Files:
  
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py


Index: 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
===
--- 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
+++ 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
@@ -5,7 +5,7 @@
 from gdbclientutils import *
 
 
-class TestThreadSelectionBug(GDBRemoteTestBase):
+class TestStopPCs(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):


Index: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
===
--- packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
+++ packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
@@ -5,7 +5,7 @@
 from gdbclientutils import *
 
 
-class TestThreadSelectionBug(GDBRemoteTestBase):
+class TestStopPCs(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D53086: [PDB] Fix flaky `variables-locations.test` after PR38857

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D53086#1261704, @aleksandr.urakov wrote:

> As for aligned stack cross-platform problems, I mean also problems with stack 
> unwinding. They seem to appear on non-Windows too. It's because 
> `x86AssemblyInspectionEngine` doesn't support stack alignment now. I've made 
> some changes locally to fix it, but they are still raw to publish. The main 
> idea is to save one more frame address (along with CFA) for every row of an 
> unwind plan (I've called this AFA - aligned frame address), and add an 
> analysis for `and esp, ...` etc. to `x86AssemblyInspectionEngine`. What do 
> you think about a such approach?


I am not sure I fully understand the discussion here (I got lost in the 
windows-specific jargon), but are we talking about the situation where a 
function re-aligns it's stack pointer on entry via some sequence like:

  mov %esp, %ebp
  and %-8, %esp
  ...
  mov %ebp, %esp
  ret

?

If so, then I don't see why the instruction emulator should have a problem with 
this sequence, because after `mov %esp, %ebp` it will conclude that the frame 
of this function is ebp-based, and use that for unwinding (I know there were 
some issues here in the past, but I hope I have fixed those already). Or are 
you saying that your compiler manages to align the stack without producing a 
frame pointer? I think that would be very tricky, as the function itself needs 
to restore the original %esp value somehow so it can return properly. Can you 
show me the disassembly of the function in question?


https://reviews.llvm.org/D53086



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

[Lldb-commits] [PATCH] D53297: [lldbsuite] Make the names of test classes unique

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

It would be great if we can detect this when all of the test files are loaded 
and emit an error instead of waiting for results to be overwritten


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53297



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

[Lldb-commits] [PATCH] D53297: [lldbsuite] Make the names of test classes unique

[Stella Stamenova 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 rLLDB344547: [lldbsuite] Make the names of test classes unique 
(authored by stella.stamenova, committed by ).

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53297

Files:
  
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py


Index: 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
===
--- 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
+++ 
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
@@ -5,7 +5,7 @@
 from gdbclientutils import *
 
 
-class TestThreadSelectionBug(GDBRemoteTestBase):
+class TestStopPCs(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):


Index: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
===
--- packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
+++ packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
@@ -5,7 +5,7 @@
 from gdbclientutils import *
 
 
-class TestThreadSelectionBug(GDBRemoteTestBase):
+class TestStopPCs(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r344547 - [lldbsuite] Make the names of test classes unique

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Mon Oct 15 12:51:21 2018
New Revision: 344547

URL: http://llvm.org/viewvc/llvm-project?rev=344547&view=rev
Log:
[lldbsuite] Make the names of test classes unique

Summary:
If the names are not unique, the tests overwrite each other's results and logs. 
This also causes failures on platforms where the files are locked for writing.

The names of the class/test pairs *have to* always be unique. The easiest way 
to achieve that is to name each class differently (usually the same as the file 
name).

Reviewers: jasonmolenda, asmith

Subscribers: clayborg, nemanjai, kbarton, lldb-commits

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py?rev=344547&r1=344546&r2=344547&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
 Mon Oct 15 12:51:21 2018
@@ -5,7 +5,7 @@ from lldbsuite.test.decorators import *
 from gdbclientutils import *
 
 
-class TestThreadSelectionBug(GDBRemoteTestBase):
+class TestStopPCs(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):


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

[Lldb-commits] [PATCH] D53208: [lldbsuite] Fix the mac version decorator to work on non-mac platforms

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

In https://reviews.llvm.org/D53208#1264056, @jingham wrote:

> We do compose the decorators in a bunch of places (like Shafik's usage here). 
>  That will work more naturally if the categories that the decorators assert 
> are as decoupled as possible.  So the statement about macos version should 
> only skip the test if the os is macos, and make no comment about other os's.  
> That decouples the macos_version test from the oslist test, and allows 
> something like the construct in the tests that Shafik wrote, which seems a 
> pretty natural way to express "if on macOS, it has to be version > x, 
> otherwise it has to be clang > y".


I updated the change to support that. Could you have a look?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53208



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

[Lldb-commits] [lldb] r344557 - Convert code to use early exits in prepraration for future changes. (NFC)

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Mon Oct 15 14:35:45 2018
New Revision: 344557

URL: http://llvm.org/viewvc/llvm-project?rev=344557&view=rev
Log:
Convert code to use early exits in prepraration for future changes. (NFC)

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp?rev=344557&r1=344556&r2=344557&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 Mon Oct 15 14:35:45 2018
@@ -204,71 +204,71 @@ bool ItaniumABILanguageRuntime::GetDynam
 
   // Only a pointer or reference type can have a different dynamic and static
   // type:
-  if (CouldHaveDynamicValue(in_value)) {
-// First job, pull out the address at 0 offset from the object.
-AddressType address_type;
-lldb::addr_t original_ptr = in_value.GetPointerValue(&address_type);
-if (original_ptr == LLDB_INVALID_ADDRESS)
-  return false;
-
-ExecutionContext exe_ctx(in_value.GetExecutionContextRef());
-
-Process *process = exe_ctx.GetProcessPtr();
-
-if (process == nullptr)
-  return false;
-
-Status error;
-const lldb::addr_t vtable_address_point =
-process->ReadPointerFromMemory(original_ptr, error);
-
-if (!error.Success() || vtable_address_point == LLDB_INVALID_ADDRESS) {
-  return false;
-}
-
-class_type_or_name = GetTypeInfoFromVTableAddress(in_value, original_ptr,
-  vtable_address_point);
-
-if (class_type_or_name) {
-  TypeSP type_sp = class_type_or_name.GetTypeSP();
-  // There can only be one type with a given name, so we've just found
-  // duplicate definitions, and this one will do as well as any other. We
-  // don't consider something to have a dynamic type if it is the same as
-  // the static type.  So compare against the value we were handed.
-  if (type_sp) {
-if (ClangASTContext::AreTypesSame(in_value.GetCompilerType(),
-  type_sp->GetForwardCompilerType())) {
-  // The dynamic type we found was the same type, so we don't have a
-  // dynamic type here...
-  return false;
-}
-
-// The offset_to_top is two pointers above the vtable pointer.
-const uint32_t addr_byte_size = process->GetAddressByteSize();
-const lldb::addr_t offset_to_top_location =
-vtable_address_point - 2 * addr_byte_size;
-// Watch for underflow, offset_to_top_location should be less than
-// vtable_address_point
-if (offset_to_top_location >= vtable_address_point)
-  return false;
-const int64_t offset_to_top = process->ReadSignedIntegerFromMemory(
-offset_to_top_location, addr_byte_size, INT64_MIN, error);
-
-if (offset_to_top == INT64_MIN)
-  return false;
-// So the dynamic type is a value that starts at offset_to_top above
-// the original address.
-lldb::addr_t dynamic_addr = original_ptr + offset_to_top;
-if (!process->GetTarget().GetSectionLoadList().ResolveLoadAddress(
-dynamic_addr, dynamic_address)) {
-  dynamic_address.SetRawAddress(dynamic_addr);
-}
-return true;
-  }
-}
+  if (!CouldHaveDynamicValue(in_value))
+return false;
+
+  // First job, pull out the address at 0 offset from the object.
+  AddressType address_type;
+  lldb::addr_t original_ptr = in_value.GetPointerValue(&address_type);
+  if (original_ptr == LLDB_INVALID_ADDRESS)
+return false;
+
+  ExecutionContext exe_ctx(in_value.GetExecutionContextRef());
+
+  Process *process = exe_ctx.GetProcessPtr();
+
+  if (process == nullptr)
+return false;
+
+  Status error;
+  const lldb::addr_t vtable_address_point =
+  process->ReadPointerFromMemory(original_ptr, error);
+
+  if (!error.Success() || vtable_address_point == LLDB_INVALID_ADDRESS)
+return false;
+
+  class_type_or_name = GetTypeInfoFromVTableAddress(in_value, original_ptr,
+vtable_address_point);
+
+  if (!class_type_or_name)
+return false;
+
+  TypeSP type_sp = class_type_or_name.GetTypeSP();
+  // There can only be one type with a given name, so we've just found
+  // duplicate definitions, and this one will do as well as any other. We
+  // don't consider something to have a dynamic type if it is the same as
+  // the static type.  So compare against the value we were handed.
+  if (!type_sp)
+return true;
+
+  if (ClangASTContext:

[Lldb-commits] [PATCH] D51934: [target] Change target create's behavior wrt loading dependent files.

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

Thanks. I guess the more explicit question is: which platforms is this feature 
(and test) applicable to? The test should be disabled on other platforms. It is 
already disabled on Linux because it is not applicable and it is failing to 
even build on Windows in its current state.

@JDevlieghere , do you expect this to work on Windows?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51934



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

[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

In https://reviews.llvm.org/D50478#1262717, @vsk wrote:

> In https://reviews.llvm.org/D50478#1262710, @stella.stamenova wrote:
>
> > Unfortunately, the bots are broken because of the FileCheck issue, so I 
> > can't confirm with them, but I see a number of these tests fail in our 
> > local testing. Some fail on both Windows and Linux and some just fail on 
> > Linux. Here are the failing tests:
> >
> >   Linux:
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
> >  
> >   Windows:
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> >   lldb-Suite :: 
> > functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
> >
> >
> > Let me know what you need to investigate.
>
>
> Strange, I didn't get any bot failure notifications in the days after this 
> landed. Could you share the output from the failing tests?


All the failures on Windows are happening when validating the function name. 
For example:

  ==
  
  FAIL: test_tail_call_frame_sbapi 
(TestTailCallFrameSBAPI.TestTailCallFrameSBAPI)
  
  --
  
  Traceback (most recent call last):
  
File 
"E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
 line 19, in test_tail_call_frame_sbapi
  
  self.do_test()
  
File 
"E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
 line 64, in do_test
  
  self.assertTrue(frame.GetDisplayFunctionName() == name)
  
  AssertionError: False is not True
  
  Config=x86_64-E:\_work\55\b\LLVMBuild\Release\bin\clang.exe
  
  --

There are several different failures on Linux. Here's the first one:

  FAIL: LLDB (/vstsdrive/_work/38/b/LLVMBuild/bin/clang-8-x86_64) :: test_dwarf 
(lldbsuite.test.lldbtest.TestDisambiguateCallSite)
  
  --- FileCheck trace (code=1) ---
  /vstsdrive/_work/38/b/LLVMBuild/bin/FileCheck 
/vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp
 -implicit-check-not=artificial
  
  FileCheck input:
  * thread #1, name = 'a.out', stop reason = breakpoint 1.1
* frame #0: 0x00400580 a.out`sink() at main.cpp:13:4 [opt]
  frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
main.cpp:28:3 [opt]
  frame #2: 0x7f980aff7830 libc.so.6`__libc_start_main + 240
  frame #3: 0x004004a9 a.out`_start + 41
  
  
  FileCheck output:
  
  
/vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp:15:17:
 error: CHECK-NEXT: expected string not found in input
   // CHECK-NEXT: func2{{.*}} [opt] [artificial]
  ^
  :3:2: note: scanning from here
   frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
main.cpp:28:3 [opt]
   ^
  :3:80: note: possible intended match here
   frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
main.cpp:28:3 [opt]

^

Let me know if you need more logs.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50478



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

[Lldb-commits] [PATCH] D53305: Simplify LocateDSYMInVincinityOfExecutable a bit, and call Symbols::DownloadObjectAndSymbolFile for .dSYM.yaa archives

[Jason Molenda via Phabricator via lldb-commits]

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

Host/common/Symbols.cpp has a method LocateDSYMInVincinityOfExecutable which 
looks for a dSYM next to a binary ("foo" + "foo.dSYM") and it looks for a dSYM 
next to a bundle ("foo.framework/foo" + "foo.framework.dSYM").  It constructed 
these two paths differently - one with strcat's one with FileSpec component 
adding, which isn't great.

This patch adds a helper function LookForDsymNextToExecutablePath which only 
knows how to look next to a given FileSpec for a dSYM.  It also knows to look 
for a .dSYM.yaa file -- yaa is a compressed archive format used inside Apple 
akin to a zip file.  Instead of having lldb manage a cache directory & 
expanding it there, I'm calling over to Symbols::DownloadObjectAndSymbolFile() 
which knows how to expand the archive on the local filesystem and give lldb the 
path to the expanded dSYM.

There aren't any tests here because the testsuite in dSYM mode exercises this 
code well.  I tried intentionally breaking the 
bundle-parent-directory-searching code and picked up more than a dozen fails, 
for instance.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53305

Files:
  source/Host/common/Symbols.cpp

Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -65,96 +65,134 @@
   return false;
 }
 
+// Given a binary exec_fspec, and a ModuleSpec with an architecture/uuid,
+// return true if there is a matching dSYM bundle next to the exec_fspec,
+// and return that value in dsym_fspec.  
+// If there is a .dSYM.yaa compressed archive next to the exec_fspec, 
+// call through Symbols::DownloadObjectAndSymbolFile to download the
+// expanded/uncompressed dSYM and return that filepath in dsym_fspec.
+
+static bool LookForDsymNextToExecutablePath(const ModuleSpec &mod_spec,
+const FileSpec &exec_fspec,
+FileSpec &dsym_fspec) {
+  ConstString filename = exec_fspec.GetFilename();
+  FileSpec dsym_directory = exec_fspec;
+  dsym_directory.RemoveLastPathComponent();
+
+  std::string dsym_filename = filename.AsCString();
+  dsym_filename += ".dSYM";
+  dsym_directory.AppendPathComponent(dsym_filename);
+  dsym_directory.AppendPathComponent("Contents");
+  dsym_directory.AppendPathComponent("Resources");
+  dsym_directory.AppendPathComponent("DWARF");
+  
+  if (dsym_directory.Exists()) {
+
+// See if the binary name exists in the dSYM DWARF
+// subdir.
+FileSpec dsym_fspec = dsym_directory;
+dsym_fspec.AppendPathComponent(filename.AsCString());
+if (dsym_fspec.Exists()
+&& FileAtPathContainsArchAndUUID(dsym_fspec, 
+ mod_spec.GetArchitecturePtr(),
+ mod_spec.GetUUIDPtr())) {
+  return true;
+}
+
+// See if we have "../CF.framework" - so we'll look for
+// CF.framework.dSYM/Contents/Resources/DWARF/CF
+// We need to drop the last suffix after '.' to match 
+// 'CF' in the DWARF subdir.
+std::string binary_name (filename.AsCString());
+auto last_dot = binary_name.find_last_of('.');
+if (last_dot != std::string::npos) {
+  binary_name.erase(last_dot);
+  dsym_fspec = dsym_directory;
+  dsym_fspec.AppendPathComponent(binary_name);
+  if (dsym_fspec.Exists()
+  && FileAtPathContainsArchAndUUID(dsym_fspec, 
+   mod_spec.GetArchitecturePtr(),
+   mod_spec.GetUUIDPtr())) {
+return true;
+  }
+}
+  } 
+  
+  // See if we have a .dSYM.yaa next to this executable path.
+  FileSpec dsym_yaa_fspec = exec_fspec;
+  dsym_yaa_fspec.RemoveLastPathComponent();
+  std::string dsym_yaa_filename = filename.AsCString();
+  dsym_yaa_filename += ".dSYM.yaa";
+  dsym_yaa_fspec.AppendPathComponent(dsym_yaa_filename);
+
+  if (dsym_yaa_fspec.Exists()) {
+ModuleSpec mutable_mod_spec = mod_spec;
+if (Symbols::DownloadObjectAndSymbolFile (mutable_mod_spec, true)
+&& mutable_mod_spec.GetSymbolFileSpec().Exists()) {
+  dsym_fspec = mutable_mod_spec.GetSymbolFileSpec();
+  return true;
+}
+  }
+
+  return false;
+}
+
+// Given a ModuleSpec with a FileSpec and optionally uuid/architecture
+// filled in, look for a .dSYM bundle next to that binary.  Returns true
+// if a .dSYM bundle is found, and that path is returned in the dsym_fspec
+// FileSpec.
+//
+// This routine looks a few directory layers above the given exec_path -
+// exec_path might be /System/Library/Frameworks/CF.framework/CF and the
+// dSYM might be /System/Library/Frameworks/CF.framework.dSYM.
+//
+// If there is a .dSYM.yaa compressed archive found next to the binary,
+// we'll call DownloadObjectAndSymbolFile to expand it into a plain .dSYM
+
 static bool LocateDSYM

Re: [Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

[Vedant Kumar via lldb-commits]

> On Oct 15, 2018, at 3:47 PM, Stella Stamenova via Phabricator 
>  wrote:
> 
> stella.stamenova added a comment.
> 
> In https://reviews.llvm.org/D50478#1262717, @vsk wrote:
> 
>> In https://reviews.llvm.org/D50478#1262710, @stella.stamenova wrote:
>> 
>>> Unfortunately, the bots are broken because of the FileCheck issue, so I 
>>> can't confirm with them, but I see a number of these tests fail in our 
>>> local testing. Some fail on both Windows and Linux and some just fail on 
>>> Linux. Here are the failing tests:
>>> 
>>>  Linux:
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
>>> 
>>>  Windows:
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
>>>  lldb-Suite :: 
>>> functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
>>> 
>>> 
>>> Let me know what you need to investigate.
>> 
>> 
>> Strange, I didn't get any bot failure notifications in the days after this 
>> landed. Could you share the output from the failing tests?
> 
> 
> All the failures on Windows are happening when validating the function name. 
> For example:
> 
>  ==
> 
>  FAIL: test_tail_call_frame_sbapi 
> (TestTailCallFrameSBAPI.TestTailCallFrameSBAPI)
> 
>  --
> 
>  Traceback (most recent call last):
> 
>File 
> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>  line 19, in test_tail_call_frame_sbapi
> 
>  self.do_test()
> 
>File 
> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>  line 64, in do_test
> 
>  self.assertTrue(frame.GetDisplayFunctionName() == name)

It could be that the display name of a function is formatted differently on 
Windows. Do you have an easy way of determining what 
frame.GetDisplayFunctionName() is?


> 
>  AssertionError: False is not True
> 
>  Config=x86_64-E:\_work\55\b\LLVMBuild\Release\bin\clang.exe
> 
>  --
> 
> There are several different failures on Linux. Here's the first one:
> 
>  FAIL: LLDB (/vstsdrive/_work/38/b/LLVMBuild/bin/clang-8-x86_64) :: 
> test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateCallSite)
> 
>  --- FileCheck trace (code=1) ---
>  /vstsdrive/_work/38/b/LLVMBuild/bin/FileCheck 
> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp
>  -implicit-check-not=artificial
> 
>  FileCheck input:
>  * thread #1, name = 'a.out', stop reason = breakpoint 1.1
>* frame #0: 0x00400580 a.out`sink() at main.cpp:13:4 [opt]
>  frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
> main.cpp:28:3 [opt]
>  frame #2: 0x7f980aff7830 libc.so.6`__libc_start_main + 240
>  frame #3: 0x004004a9 a.out`_start + 41

It looks like we're not generating tail call frames on Linux at all. It would 
help to have logs from "log enable -f /tmp/linux-stepping.log lldb step".

I'm headed out of the office now, but If you need to disable the tests on 
Windows/Linux , the fastest way to do that would be to add a platform check to 
skipUnlessHasCallSiteInfo in decorators.py.

vedant


> 
> 
>  FileCheck output:
> 
>  
> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp:15:17:
>  error: CHECK-NEXT: expected string not found in input
>   // CHECK-NEXT: func2{{.*}} [opt] [artificial]
>  ^
>  :3:2: note: scanning from here
>   frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
> main.cpp:28:3 [opt]
>   ^
>  :3:80: note: possible intended match here
>   frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
> main.cpp:28:3 [opt]
>   
>  ^
> 
> Let me know if you need more logs.
> 
> 
> Repository:
>  rLLDB LLDB
> 
> https://reviews.llvm.org/D50478
> 
> 
> 

___
lldb-com

Re: [Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

[Frédéric Riss via lldb-commits]

> On Oct 15, 2018, at 4:40 PM, Vedant Kumar  wrote:
> 
> 
> 
>> On Oct 15, 2018, at 3:47 PM, Stella Stamenova via Phabricator 
>>  wrote:
>> 
>> stella.stamenova added a comment.
>> 
>> In https://reviews.llvm.org/D50478#1262717, @vsk wrote:
>> 
>>> In https://reviews.llvm.org/D50478#1262710, @stella.stamenova wrote:
>>> 
 Unfortunately, the bots are broken because of the FileCheck issue, so I 
 can't confirm with them, but I see a number of these tests fail in our 
 local testing. Some fail on both Windows and Linux and some just fail on 
 Linux. Here are the failing tests:
 
 Linux:
 lldb-Suite :: 
 functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
 lldb-Suite :: 
 functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
 lldb-Suite :: 
 functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
 lldb-Suite :: 
 functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
 lldb-Suite :: 
 functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
 lldb-Suite :: 
 functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
 lldb-Suite :: 
 functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
 
 Windows:
 lldb-Suite :: 
 functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
 lldb-Suite :: 
 functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
 
 
 Let me know what you need to investigate.
>>> 
>>> 
>>> Strange, I didn't get any bot failure notifications in the days after this 
>>> landed. Could you share the output from the failing tests?
>> 
>> 
>> All the failures on Windows are happening when validating the function name. 
>> For example:
>> 
>> ==
>> 
>> FAIL: test_tail_call_frame_sbapi 
>> (TestTailCallFrameSBAPI.TestTailCallFrameSBAPI)
>> 
>> --
>> 
>> Traceback (most recent call last):
>> 
>>   File 
>> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>>  line 19, in test_tail_call_frame_sbapi
>> 
>> self.do_test()
>> 
>>   File 
>> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>>  line 64, in do_test
>> 
>> self.assertTrue(frame.GetDisplayFunctionName() == name)
> 
> It could be that the display name of a function is formatted differently on 
> Windows. Do you have an easy way of determining what 
> frame.GetDisplayFunctionName() is?

If you use assertEqual(a,b) instead of assertTrue, it will print out the values 
and make it easier to debug.

Fred 

> 
>> 
>> AssertionError: False is not True
>> 
>> Config=x86_64-E:\_work\55\b\LLVMBuild\Release\bin\clang.exe
>> 
>> --
>> 
>> There are several different failures on Linux. Here's the first one:
>> 
>> FAIL: LLDB (/vstsdrive/_work/38/b/LLVMBuild/bin/clang-8-x86_64) :: 
>> test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateCallSite)
>> 
>> --- FileCheck trace (code=1) ---
>> /vstsdrive/_work/38/b/LLVMBuild/bin/FileCheck 
>> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp
>>  -implicit-check-not=artificial
>> 
>> FileCheck input:
>> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
>>   * frame #0: 0x00400580 a.out`sink() at main.cpp:13:4 [opt]
>> frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
>> main.cpp:28:3 [opt]
>> frame #2: 0x7f980aff7830 libc.so.6`__libc_start_main + 240
>> frame #3: 0x004004a9 a.out`_start + 41
> 
> It looks like we're not generating tail call frames on Linux at all. It would 
> help to have logs from "log enable -f /tmp/linux-stepping.log lldb step".
> 
> I'm headed out of the office now, but If you need to disable the tests on 
> Windows/Linux , the fastest way to do that would be to add a platform check 
> to skipUnlessHasCallSiteInfo in decorators.py.
> 
> vedant
> 
> 
>> 
>> 
>> FileCheck output:
>> 
>> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp:15:17:
>>  error: CHECK-NEXT: expected string not found in input
>>  // CHECK-NEXT: func2{{.*}} [opt] [artificial]
>> ^
>> :3:2: note: scanning from here
>>  frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
>> main.cpp:28:3 [opt]
>>  ^
>> :3:80: note: possible intended match here
>>  frame #1: 0x004005b8 a.out`main(argc=1, (null)=) at 
>> main.cpp:

[Lldb-commits] [PATCH] D51934: [target] Change target create's behavior wrt loading dependent files.

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

I wouldn't be surprised if Jonas isn't familiar enough with the Windows port to 
answer the question.  But if you have a running lldb you can tell easily.  Just 
do:

lldb SomeBinaryThatLoadsSharedLibraries
(lldb) image list

Do you get only SomeBinaryThatLoadsSharedLibraries, or do you get a list of the 
dependencies of the binary as well?  If the former, then this test won't test 
anything for you.  If the latter, then this test will test something real, and 
we should figure out how to get the test to build on Windows.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51934



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

[Lldb-commits] [PATCH] D53208: [lldbsuite] Fix the mac version decorator to work on non-mac platforms

[Jim Ingham via Phabricator via lldb-commits]

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

That seems more convenient to me, it makes the mac version only relevant if you 
are on a mac.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53208



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

[Lldb-commits] [PATCH] D53309: Return a useful "Error" for an expression that completes but produces no result

[Jim Ingham via Phabricator via lldb-commits]

jingham created this revision.
Herald added subscribers: lldb-commits, abidh, JDevlieghere.

When you run an expression like:

(lldb) expr int $x = 10

the expression has no result.  The ValueObject (and then SBValue) you get back 
from the expression signals that by putting an error indicating this in the 
Status object returned by SBValue::GetError().  Unfortunately, this error was 
not terribly helpful.  The error number was a private constant that only 
UserExpression knew about, and the error string was unset.  This meant you 
couldn't really trust the result of SBValue.GetError().Success() when you ran 
an expression.

This commit adds an eExpressionProducedNoResult constant to the 
ExpressionResults enum, and used that and an appropriate string in the error 
object.  So now you can usefully tell the difference between an expression that 
produces no result and one that failed.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53309

Files:
  include/lldb/Expression/UserExpression.h
  include/lldb/lldb-enumerations.h
  packages/Python/lldbsuite/test/expression_command/no-result/Makefile
  packages/Python/lldbsuite/test/expression_command/no-result/TestNoResult.py
  packages/Python/lldbsuite/test/expression_command/no-result/main.c
  source/Commands/CommandObjectExpression.cpp
  source/Expression/REPL.cpp
  source/Expression/UserExpression.cpp
  
source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp

Index: packages/Python/lldbsuite/test/expression_command/no-result/main.c
===
--- packages/Python/lldbsuite/test/expression_command/no-result/main.c
+++ packages/Python/lldbsuite/test/expression_command/no-result/main.c
@@ -0,0 +1,9 @@
+#include 
+
+int
+main()
+{
+  int test_var = 10;
+  printf ("Set a breakpoint here: %d.\n", test_var);
+  return 0;
+}
Index: packages/Python/lldbsuite/test/expression_command/no-result/TestNoResult.py
===
--- packages/Python/lldbsuite/test/expression_command/no-result/TestNoResult.py
+++ packages/Python/lldbsuite/test/expression_command/no-result/TestNoResult.py
@@ -0,0 +1,45 @@
+"""
+Test that an expression that returns no result returns a sensible error.
+"""
+
+from __future__ import print_function
+
+
+import os
+import time
+import re
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class TestExprNoResult(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_no_result(self):
+"""Run an expression that has no result, check the error."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.sample_test()
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+def sample_test(self):
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(self,
+   "Set a breakpoint here", self.main_source_file)
+
+frame = thread.GetFrameAtIndex(0)
+result = frame.EvaluateExpression("int $x = 10")
+# No result expressions are considered to fail:
+self.assertTrue(result.GetError().Fail(), "An expression with no result is a failure.")
+# But the reason should be eExpressionProducedNoResult
+self.assertEqual(result.GetError().GetError(), lldb.eExpressionProducedNoResult, 
+ "But the right kind of failure")
Index: packages/Python/lldbsuite/test/expression_command/no-result/Makefile
===
--- packages/Python/lldbsuite/test/expression_command/no-result/Makefile
+++ packages/Python/lldbsuite/test/expression_command/no-result/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+CFLAGS_EXTRAS += -std=c99
+
+include $(LEVEL)/Makefile.rules
Index: source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
===
--- source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
+++ source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
@@ -1758,7 +1758,7 @@
   if (!expr_result->GetError().Success()) {
 Status err = expr_result->GetError();
 // Expression returned is void, so this is actually a success
-if (err.GetError() == UserExpression::kNoResult) {
+if (err.GetError() == lldb::eExpressionProducedNoResult) {
   if (log)
 log->Printf("%s - expression returned void.", __FUNCTION__);
 
Index: source/Expression/UserExpression.cpp
===
--- source/Expression/UserExpr

[Lldb-commits] [PATCH] D53193: [LLDB] - Add support for DW_RLE_start_end entries (.debug_rnglists)

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

The code and test look correct, so this LGTM but I'll leave it open for now in 
case someone else wants to have a look too.


https://reviews.llvm.org/D53193



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

[Lldb-commits] [lldb] r344581 - Use assertEqual to improve test failure logging

[Vedant Kumar via lldb-commits]

Author: vedantk
Date: Mon Oct 15 20:31:33 2018
New Revision: 344581

URL: http://llvm.org/viewvc/llvm-project?rev=344581&view=rev
Log:
Use assertEqual to improve test failure logging

Some tests in test/functionalities/tail_call_frames are failing on
non-Darwin platforms. Use assertEqual to improve logging on failure.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py?rev=344581&r1=344580&r2=344581&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
 Mon Oct 15 20:31:33 2018
@@ -43,11 +43,11 @@ class TestTailCallFrameSBAPI(TestBase):
 # Did we hit our breakpoint?
 threads = lldbutil.get_threads_stopped_at_breakpoint(process,
 breakpoint)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "There should be a thread stopped at our breakpoint")
 
-self.assertTrue(breakpoint.GetHitCount() == 1)
+self.assertEqual(breakpoint.GetHitCount(), 1)
 
 thread = threads[0]
 
@@ -61,5 +61,5 @@ class TestTailCallFrameSBAPI(TestBase):
 artificiality = [False, True, False, True, False]
 for idx, (name, is_artificial) in enumerate(zip(names, artificiality)):
 frame = thread.GetFrameAtIndex(idx)
-self.assertTrue(frame.GetDisplayFunctionName() == name)
-self.assertTrue(frame.IsArtificial() == is_artificial)
+self.assertEqual(frame.GetDisplayFunctionName(), name)
+self.assertEqual(frame.IsArtificial(), is_artificial)

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py?rev=344581&r1=344580&r2=344581&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
 Mon Oct 15 20:31:33 2018
@@ -35,11 +35,11 @@ class TestArtificialFrameThreadStepOut1(
 # Did we hit our breakpoint?
 threads = lldbutil.get_threads_stopped_at_breakpoint(process,
 breakpoint)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "There should be a thread stopped at our breakpoint")
 
-self.assertTrue(breakpoint.GetHitCount() == 1)
+self.assertEqual(breakpoint.GetHitCount(), 1)
 
 thread = threads[0]
 
@@ -59,13 +59,13 @@ class TestArtificialFrameThreadStepOut1(
 # frame #2, because we behave as-if artificial frames were not present.
 thread.StepOut()
 frame2 = thread.GetSelectedFrame()
-self.assertTrue(frame2.GetDisplayFunctionName() == "func2()")
+self.assertEqual(frame2.GetDisplayFunctionName(), "func2()")
 self.assertFalse(frame2.IsArtificial())
 
 # Ditto: stepping out of frame #2 should move to frame #4.
 thread.StepOut()
 frame4 = thread.GetSelectedFrame()
-self.assertTrue(frame4.GetDisplayFunctionName() == "main")
+self.assertEqual(frame4.GetDisplayFunctionName(), "main")
 self.assertFalse(frame2.IsArtificial())
 
 def test_return_past_artificial_frame(self):
@@ -78,13 +78,13 @@ class TestArtificialFrameThreadStepOut1(
 # to frame #2.
 thread.ReturnFromFrame(thread.GetSelectedFrame(), value)
 frame2 = thread.GetSelectedFrame()
-self.assertTrue(frame2.GetDisplayFunctionName() == "func2()")
+self.assertEqual(frame2.GetDisplayFunctionName(), "func2()")
 self.assertFalse(frame2.IsArtificial())
 
 # Ditto: stepping out of frame #2 should move to frame #4.
 thread.ReturnFromFrame(thread.GetSelectedFrame(), value)
 frame4 = thread.GetSelectedFrame()
-self.assertTrue

Re: [Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

[Vedant Kumar via lldb-commits]

> On Oct 15, 2018, at 4:46 PM, Frédéric Riss  wrote:
> 
> 
> 
>> On Oct 15, 2018, at 4:40 PM, Vedant Kumar > > wrote:
>> 
>> 
>> 
>>> On Oct 15, 2018, at 3:47 PM, Stella Stamenova via Phabricator 
>>> mailto:revi...@reviews.llvm.org>> wrote:
>>> 
>>> stella.stamenova added a comment.
>>> 
>>> In https://reviews.llvm.org/D50478#1262717 
>>> , @vsk wrote:
>>> 
 In https://reviews.llvm.org/D50478#1262710 
 , @stella.stamenova wrote:
 
> Unfortunately, the bots are broken because of the FileCheck issue, so I 
> can't confirm with them, but I see a number of these tests fail in our 
> local testing. Some fail on both Windows and Linux and some just fail on 
> Linux. Here are the failing tests:
> 
> Linux:
> lldb-Suite :: 
> functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
> lldb-Suite :: 
> functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
> lldb-Suite :: 
> functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
> lldb-Suite :: 
> functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
> lldb-Suite :: 
> functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> lldb-Suite :: 
> functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
> lldb-Suite :: 
> functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
> 
> Windows:
> lldb-Suite :: 
> functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> lldb-Suite :: 
> functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
> 
> 
> Let me know what you need to investigate.
 
 
 Strange, I didn't get any bot failure notifications in the days after this 
 landed. Could you share the output from the failing tests?
>>> 
>>> 
>>> All the failures on Windows are happening when validating the function 
>>> name. For example:
>>> 
>>> ==
>>> 
>>> FAIL: test_tail_call_frame_sbapi 
>>> (TestTailCallFrameSBAPI.TestTailCallFrameSBAPI)
>>> 
>>> --
>>> 
>>> Traceback (most recent call last):
>>> 
>>>   File 
>>> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>>>  line 19, in test_tail_call_frame_sbapi
>>> 
>>> self.do_test()
>>> 
>>>   File 
>>> "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py",
>>>  line 64, in do_test
>>> 
>>> self.assertTrue(frame.GetDisplayFunctionName() == name)
>> 
>> It could be that the display name of a function is formatted differently on 
>> Windows. Do you have an easy way of determining what 
>> frame.GetDisplayFunctionName() is?
> 
> If you use assertEqual(a,b) instead of assertTrue, it will print out the 
> values and make it easier to debug.

Thanks, done in r344581.

vedant

> 
> Fred 
> 
>> 
>>> 
>>> AssertionError: False is not True
>>> 
>>> Config=x86_64-E:\_work\55\b\LLVMBuild\Release\bin\clang.exe
>>> 
>>> --
>>> 
>>> There are several different failures on Linux. Here's the first one:
>>> 
>>> FAIL: LLDB (/vstsdrive/_work/38/b/LLVMBuild/bin/clang-8-x86_64) :: 
>>> test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateCallSite)
>>> 
>>> --- FileCheck trace (code=1) ---
>>> /vstsdrive/_work/38/b/LLVMBuild/bin/FileCheck 
>>> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp
>>>  -implicit-check-not=artificial
>>> 
>>> FileCheck input:
>>> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
>>>   * frame #0: 0x00400580 a.out`sink() at main.cpp:13:4 [opt]
>>> frame #1: 0x004005b8 a.out`main(argc=1, (null)=) 
>>> at main.cpp:28:3 [opt]
>>> frame #2: 0x7f980aff7830 libc.so.6`__libc_start_main + 240
>>> frame #3: 0x004004a9 a.out`_start + 41
>> 
>> It looks like we're not generating tail call frames on Linux at all. It 
>> would help to have logs from "log enable -f /tmp/linux-stepping.log lldb 
>> step".
>> 
>> I'm headed out of the office now, but If you need to disable the tests on 
>> Windows/Linux , the fastest way to do that would be to add a platform check 
>> to skipUnlessHasCallSiteInfo in decorators.py.
>> 
>> vedant
>> 
>> 
>>> 
>>> 
>>> FileCheck output:
>>> 
>>> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp:15: