[Lldb-commits] [PATCH] D79757: Try IPv4 before IPv6 when creating TCP connection

2020-05-12 Thread Emre Kultursay via Phabricator via lldb-commits
emrekultursay added a comment.

In D79757#2031186 , @labath wrote:

> ...
>  Where do the addresses that we're connecting to come from (the user or lldb 
> code)? If it's lldb code, maybe we could just replace the relevant 
> "localhost" names with an explicit ipv4 loopback address?


This is great feedback, thank you! yes, it was just two places that had 
"localhost" hard-coded, and just by changing it to ipv4 loopback address, I 
achieved the same improvement. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79757



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


[Lldb-commits] [PATCH] D79757: Try IPv4 before IPv6 when creating TCP connection

2020-05-12 Thread Emre Kultursay via Phabricator via lldb-commits
emrekultursay updated this revision to Diff 263599.
emrekultursay added a comment.

Enforce IPv4 usage only in Android code, revert non-Android changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79757

Files:
  lldb/source/Plugins/Platform/Android/AdbClient.cpp
  lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp


Index: lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
===
--- lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
+++ lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
@@ -188,7 +188,7 @@
 if (error.Success()) {
   m_port_forwards[pid] = local_port;
   std::ostringstream url_str;
-  url_str << "connect://localhost:" << local_port;
+  url_str << "connect://127.0.0.1:" << local_port;
   connect_url = url_str.str();
   break;
 }
Index: lldb/source/Plugins/Platform/Android/AdbClient.cpp
===
--- lldb/source/Plugins/Platform/Android/AdbClient.cpp
+++ lldb/source/Plugins/Platform/Android/AdbClient.cpp
@@ -141,7 +141,7 @@
   if (const char *env_port = std::getenv("ANDROID_ADB_SERVER_PORT")) {
 port = env_port;
   }
-  std::string uri = "connect://localhost:" + port;
+  std::string uri = "connect://127.0.0.1:" + port;
   m_conn->Connect(uri.c_str(), );
 
   return error;


Index: lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
===
--- lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
+++ lldb/source/Plugins/Platform/Android/PlatformAndroidRemoteGDBServer.cpp
@@ -188,7 +188,7 @@
 if (error.Success()) {
   m_port_forwards[pid] = local_port;
   std::ostringstream url_str;
-  url_str << "connect://localhost:" << local_port;
+  url_str << "connect://127.0.0.1:" << local_port;
   connect_url = url_str.str();
   break;
 }
Index: lldb/source/Plugins/Platform/Android/AdbClient.cpp
===
--- lldb/source/Plugins/Platform/Android/AdbClient.cpp
+++ lldb/source/Plugins/Platform/Android/AdbClient.cpp
@@ -141,7 +141,7 @@
   if (const char *env_port = std::getenv("ANDROID_ADB_SERVER_PORT")) {
 port = env_port;
   }
-  std::string uri = "connect://localhost:" + port;
+  std::string uri = "connect://127.0.0.1:" + port;
   m_conn->Connect(uri.c_str(), );
 
   return error;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 67087a7 - [LLDB] Fix typo in xfail decorator assert.test

2020-05-12 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-05-13T08:53:56+05:00
New Revision: 67087a7b76599ea783c1d930f0c2047deaa8fbae

URL: 
https://github.com/llvm/llvm-project/commit/67087a7b76599ea783c1d930f0c2047deaa8fbae
DIFF: 
https://github.com/llvm/llvm-project/commit/67087a7b76599ea783c1d930f0c2047deaa8fbae.diff

LOG: [LLDB] Fix typo in xfail decorator assert.test

Fix a typo in earlier xfailed assert.test replace // with #.

Added: 


Modified: 
lldb/test/Shell/Recognizer/assert.test

Removed: 




diff  --git a/lldb/test/Shell/Recognizer/assert.test 
b/lldb/test/Shell/Recognizer/assert.test
index 7a96f3610ec5..d3eb9c8da7c9 100644
--- a/lldb/test/Shell/Recognizer/assert.test
+++ b/lldb/test/Shell/Recognizer/assert.test
@@ -1,4 +1,4 @@
-// XFAIL: target-arm && linux-gnu
+# XFAIL: target-arm && linux-gnu
 # UNSUPPORTED: system-windows
 # RUN: %clang_host -g -O0 %S/Inputs/assert.c -o %t.out
 # RUN: %lldb -b -s %s %t.out | FileCheck %s



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


[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread António Afonso via Phabricator via lldb-commits
aadsm marked an inline comment as done.
aadsm added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py:250-251
 def cleanup():
-self.vscode.request_disconnect(terminateDebuggee=True)
+if disconnect:
+self.vscode.request_disconnect(terminateDebuggee=True)
 self.vscode.terminate()

aadsm wrote:
> labath wrote:
> > aadsm wrote:
> > > labath wrote:
> > > > What's the purpose of this argument? To ensure a clean shutdown? Would 
> > > > it be possible to make the function smart enough to detect the right 
> > > > thing to do when cleaning up?
> > > it indicates if the process should be killed or not when lldb-vscode 
> > > disconnects from it.
> > I meant the `disconnect` argument to the `attach` function in the test 
> > suite , not the `terminateDebuggee` argument of the `disconnect` command to 
> > lldb-vscode.
> > 
> > My point is that, given the way the cleanup functions work, you cannot 
> > assume that you're going to be invoked in any particular moment. For 
> > example they can called if an assertion fails, to ensure any external 
> > resources/processes are terminated. Since you don't know which assertion 
> > will fail, it's best if you don't assume anything about the the state of 
> > the inferior and just do your best to clean up. I'm not sure what "doing 
> > your best" would mean here. For example it may mean sending a "terminate" 
> > request and ignoring errors. Or maybe a better solution is possible...
> oh yeah of course, the argument I added . Oh, you know what, I misread when 
> the cleanup function was going to be called. I don't need this at all, will 
> remove it.
sorry about this, I remember now (I've been working on something else not 
related to this when I replied).

I did it this way so I can explicitly say that I don't want the test to 
automatically disconnect when it's teared down. I need to disconnect manually 
so I can test the terminateCommands, and and 2 disconnects won't work well 
because we'll be waiting for that answer that will never arrive, since it has 
already been terminated.

Another way to do this, that I thought at the time, was to track if the test is 
connected or not and only disconnect in that situation. I opted to not do that 
in the end because I wanted this behaviour to be intentional in the test, to 
prevent something from disconnecting (unintentionally, like a bug) and then the 
teardown will skip it and that error would never be surfaced. This might be a 
bit overzealous though...

what do you think?





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [lldb] 6805a77 - [LLDB] Mark some xfails for arm-linux

2020-05-12 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-05-13T08:05:27+05:00
New Revision: 6805a77eb66e2e4c9f308bc49c77297f790a5e7b

URL: 
https://github.com/llvm/llvm-project/commit/6805a77eb66e2e4c9f308bc49c77297f790a5e7b
DIFF: 
https://github.com/llvm/llvm-project/commit/6805a77eb66e2e4c9f308bc49c77297f790a5e7b.diff

LOG: [LLDB] Mark some xfails for arm-linux

This patch marks following tests as xfail for arm-linux target.

lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test

Bugs have been filed for all of them for the corresponding failing
component.

Added: 


Modified: 
lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test

Removed: 




diff  --git 
a/lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py 
b/lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
index 0adb3d09b606..a7d5f07a0976 100644
--- a/lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
+++ b/lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
@@ -40,6 +40,7 @@ def setUp(self):
 @not_remote_testsuite_ready
 @skipIfWindows  # Windows doesn't have dlopen and friends, dynamic 
libraries work 
diff erently
 @expectedFlakeyNetBSD
+@expectedFailureAll(oslist=["linux"], archs=['arm'], 
bugnumber="llvm.org/pr45894")
 def test_load_using_paths(self):
 """Test that we can load a module by providing a set of search 
paths."""
 if self.platformIsDarwin():

diff  --git a/lldb/test/API/python_api/thread/TestThreadAPI.py 
b/lldb/test/API/python_api/thread/TestThreadAPI.py
index 87d4eb8ae712..6e4aeddc82c9 100644
--- a/lldb/test/API/python_api/thread/TestThreadAPI.py
+++ b/lldb/test/API/python_api/thread/TestThreadAPI.py
@@ -38,6 +38,7 @@ def test_run_to_address(self):
 self.run_to_address(self.exe_name)
 
 @add_test_categories(['pyapi'])
+@expectedFailureAll(oslist=["linux"], archs=['arm'], 
bugnumber="llvm.org/pr45892")
 @expectedFailureAll(oslist=['freebsd'], bugnumber='llvm.org/pr20476')
 @expectedFailureAll(oslist=["windows"])
 @expectedFailureNetBSD

diff  --git a/lldb/test/Shell/Recognizer/assert.test 
b/lldb/test/Shell/Recognizer/assert.test
index 9b4aa21611e0..7a96f3610ec5 100644
--- a/lldb/test/Shell/Recognizer/assert.test
+++ b/lldb/test/Shell/Recognizer/assert.test
@@ -1,3 +1,4 @@
+// XFAIL: target-arm && linux-gnu
 # UNSUPPORTED: system-windows
 # RUN: %clang_host -g -O0 %S/Inputs/assert.c -o %t.out
 # RUN: %lldb -b -s %s %t.out | FileCheck %s



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


[Lldb-commits] [lldb] 302c492 - [LLDB] Fix minidebuginfo-set-and-hit-breakpoint.test for arm 32-bit

2020-05-12 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-05-13T07:17:40+05:00
New Revision: 302c492cc5d97cf10837e71e4ee5872c01bc3682

URL: 
https://github.com/llvm/llvm-project/commit/302c492cc5d97cf10837e71e4ee5872c01bc3682
DIFF: 
https://github.com/llvm/llvm-project/commit/302c492cc5d97cf10837e71e4ee5872c01bc3682.diff

LOG: [LLDB] Fix minidebuginfo-set-and-hit-breakpoint.test for arm 32-bit

This patch fixes minidebuginfo-set-and-hit-breakpoint.test for arm-linux
targets. 32-bit elf executables use .rel.dyn and 64-bit uses .rela.dyn for
relocation entries for dynamic symbols.

Added: 


Modified: 
lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test

Removed: 




diff  --git 
a/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test 
b/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
index 84c69bea87f7..9507c5d6d17f 100644
--- a/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
+++ b/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
@@ -41,7 +41,7 @@
 # in the .dynsym section of the main binary. The bits removing .rela.plt,
 # .rela.dyn and .dynsym sections can be removed once llvm-objcopy
 # --only-keep-debug starts to work.
-# RUN: llvm-objcopy --remove-section=.rela.plt --remove-section=.rela.dyn \
+# RUN: llvm-objcopy --remove-section=.rela.plt --remove-section=.rela.dyn 
--remove-section=.rel.plt --remove-section=.rel.dyn \
 # RUN:   --remove-section=.gnu.version --remove-section=.gnu.hash 
--remove-section=.hash --remove-section=.dynsym %t.mini_debuginfo
 
 # Drop the full debug info from the original binary.



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


[Lldb-commits] [PATCH] D79219: [CMake] Simplify CMake handling for zlib

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: llvm/cmake/config-ix.cmake:514
+  if(ZLIB_FOUND)
+set(LLVM_ENABLE_ZLIB "YES" CACHE STRING
+  "Use zlib for compression/decompression if available. Can be ON, OFF, or 
FORCE_ON"

JDevlieghere wrote:
> phosek wrote:
> > JDevlieghere wrote:
> > > If I understand correctly, after running the configuration phase with 
> > > LLVM_ENABLE_ZLIB to FORCE_ON, the cached value will be overwritten by ON? 
> > Correct, we used `FORCE_ON` above when invoking `find_package` setting 
> > `REQUIRED` which makes the check fail if the library is missing. Recording 
> > this information is important for LLVM consumers because it'll be stored in 
> > `LLVMConfig.cmake` and AFAIU we don't want to propagate `FORCE_ON` there.
> I get that. My worry is that if for whatever reason the library disappears 
> (system upgrade, package removal, ...) this will silently disable ZLIB 
> support because now LLVM_ENABLE_ZLIB just equals on. This might sound far 
> fetched, but happens all the time with "internal installs". This is why I 
> prefer the ON/OFF/Auto approach because it doesn't update the cache variable, 
> but would set the internal variable to either ON or OFF.
I agree with Jonas, though I don't think the actual values (FORCE_ON/ON vs. 
ON/Auto) really matter here. The important part is not overwriting the cache 
variables specified by the user, as that can create various problems with 
reconfigurations (like the zlib becoming unavailable example).


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

https://reviews.llvm.org/D79219



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


[Lldb-commits] [PATCH] D79823: [lldb][Core] Remove dead codepath in Mangled

2020-05-12 Thread Alex Langford via Phabricator via lldb-commits
xiaobai added a comment.

In D79823#2032827 , @davide wrote:

> I'm curious what happens if you end up here with something like `_T`. Did you 
> check?


I assume you're talking about swift, which should be handled by a 
`SwiftLanguage` plugin. Can Objective-C names be mangled with the swift 
mangling scheme?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79823



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


[Lldb-commits] [PATCH] D79777: Fix error in TestNumThreads.py when frame.GetFunctionName returns none

2020-05-12 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0796b170fb3b: Fix error in TestNumThreads.py when 
frame.GetFunctionName returns none (authored by omjavaid).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79777

Files:
  lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py


Index: lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
===
--- lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
+++ lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
@@ -95,6 +95,8 @@
 # the same breakpoint.
 def is_thread3(thread):
 for frame in thread:
+if frame.GetFunctionName() is None:
+continue
 if "thread3" in frame.GetFunctionName(): return True
 return False
 


Index: lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
===
--- lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
+++ lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
@@ -95,6 +95,8 @@
 # the same breakpoint.
 def is_thread3(thread):
 for frame in thread:
+if frame.GetFunctionName() is None:
+continue
 if "thread3" in frame.GetFunctionName(): return True
 return False
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D79823: [lldb][Core] Remove dead codepath in Mangled

2020-05-12 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

I'm curious what happens if you end up here with something like `_T`. Did you 
check?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79823



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


[Lldb-commits] [PATCH] D79823: [lldb][Core] Remove dead codepath in Mangled

2020-05-12 Thread Davide Italiano via Phabricator via lldb-commits
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

Presumably.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79823



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


[Lldb-commits] [lldb] 0796b17 - Fix error in TestNumThreads.py when frame.GetFunctionName returns none

2020-05-12 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-05-13T05:13:46+05:00
New Revision: 0796b170fb3bf38e6cc4e59746120b37c9a9cd9f

URL: 
https://github.com/llvm/llvm-project/commit/0796b170fb3bf38e6cc4e59746120b37c9a9cd9f
DIFF: 
https://github.com/llvm/llvm-project/commit/0796b170fb3bf38e6cc4e59746120b37c9a9cd9f.diff

LOG: Fix error in TestNumThreads.py when frame.GetFunctionName returns none

Summary:
This patch fixes an error happening in TestNumThreads.py when it encounters 
frame.GetFunctionName none for address only locations in stripped libc.

This error was showing up on arm-linux docker container running lldb buildbot.

Reviewers: labath

Reviewed By: labath

Subscribers: kristof.beyls, lldb-commits

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

Added: 


Modified: 
lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py 
b/lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
index cfd2941ad193..7a4a6d05d3f2 100644
--- a/lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
+++ b/lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
@@ -95,6 +95,8 @@ def test_unique_stacks(self):
 # the same breakpoint.
 def is_thread3(thread):
 for frame in thread:
+if frame.GetFunctionName() is None:
+continue
 if "thread3" in frame.GetFunctionName(): return True
 return False
 



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


[Lldb-commits] [PATCH] D79614: Fix error reporting for qLaunchSuccess, check for fix/enable it via qSupported

2020-05-12 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In D79614#2030692 , @jasonmolenda 
wrote:

> Thanks for the feedback.
>
> In D79614#2029157 , @labath wrote:
>
> > I think that "piggy-backing" on the `qSupported` packet for communicating 
> > protocol fixes is a good idea. However, I agree with Greg, that it does not 
> > seem like it's needed for this case. Fixing the problem purely on the 
> > debugserver side seems preferable, as it avoids adding compatibility code 
> > to lldb. It's true that it's a one-off error reporting mechanism, but it's 
> > already there, so it seems better to just support what's already 
> > implemented then try to support two mechanisms.
> >
> > For a long-term solution, I am wondering whether we need `qLaunchSuccess` 
> > at all? It seems like the packet is completely redundant in a world where 
> > we can return textual error messages to _any_ packet. What was the reason 
> > for introducing it in the first place? Could we just switch to using error 
> > replies to the `A` packet for communicating the launch errors (with some 
> > transition plan for supporting `qLaunchSuccess` for a while)?
>
>
> It's hard to tell what we were thinking (GREG :) back when we used the A 
> packet to set the binary name / arguments /etc, and then the qLaunchSuccess 
> packet to start the process.  Reading over the current era gdb Remote Serial 
> Protocol docs, I think the vRun packet does the combination of these two 
> things in one packet, which makes sense.


There was no "just return error strings" packet that I was aware of. The 
problem is identifying a correct error packet. Typically you can get some 
canned responses to packets:

- "" (empty) response means not supported
- "EXX" where XX is a hex code only
- "OK" if the packet was successful
- open ended output

How do error strings get returned when not using the EXX format? Are they 
safely prefixed with something? Do they just start with "E" and then a string? 
If so, how would you tell the difference between the response "Everyone has a 
string" and "Einvalid path error"? Or does this only apply to a packet that 
returns an error if some setting was enabled with a previous  "Q" packet?

> I tested a patch using Greg's suggestion of using the binary escape protocol 
> for the error string and that does work, as expected, I'll land the patch 
> like that.

Much easier, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79614



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


[Lldb-commits] [PATCH] D79825: [lldb/Reproducers] Add test-specific API to set the test CWD

2020-05-12 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: labath, teemperor, friss.

The reproducers' working directory is set to the current working directory when
they are initialized. While this is not optimal, as the cwd can change during a
debug session, it has been sufficient so far.

The current approach doesn't work for the API test suite however because dotest
temporarily changes the directory to where the test's Python file lives.

This patch adds an API to tell the reproducers what to set the CWD to. This is
a NO-OP in every mode but capture.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D79825

Files:
  lldb/bindings/interface/SBReproducer.i
  lldb/include/lldb/API/SBReproducer.h
  lldb/include/lldb/Utility/Reproducer.h
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/API/SBReproducer.cpp


Index: lldb/source/API/SBReproducer.cpp
===
--- lldb/source/API/SBReproducer.cpp
+++ lldb/source/API/SBReproducer.cpp
@@ -231,6 +231,12 @@
   return path.c_str();
 }
 
+void SBReproducer::SetWorkingDirectory(const char *path) {
+  if (auto *g = lldb_private::repro::Reproducer::Instance().GetGenerator()) {
+g->GetOrCreate().Update(path);
+  }
+}
+
 char lldb_private::repro::SBProvider::ID = 0;
 const char *SBProvider::Info::name = "sbapi";
 const char *SBProvider::Info::file = "sbapi.bin";
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -526,6 +526,7 @@
 if traceAlways:
 print("Change dir to:", full_dir, file=sys.stderr)
 os.chdir(full_dir)
+lldb.SBReproducer.SetWorkingDirectory(full_dir)
 
 # Set platform context.
 cls.platformContext = lldbplatformutil.createPlatformContext()
Index: lldb/include/lldb/Utility/Reproducer.h
===
--- lldb/include/lldb/Utility/Reproducer.h
+++ lldb/include/lldb/Utility/Reproducer.h
@@ -147,6 +147,9 @@
   return;
 m_cwd = std::string(cwd.str());
   }
+
+  void Update(llvm::StringRef path) { m_cwd = std::string(path); }
+
   struct Info {
 static const char *name;
 static const char *file;
Index: lldb/include/lldb/API/SBReproducer.h
===
--- lldb/include/lldb/API/SBReproducer.h
+++ lldb/include/lldb/API/SBReproducer.h
@@ -26,6 +26,13 @@
   static const char *GetPath();
   static bool SetAutoGenerate(bool b);
   static bool Generate();
+
+  /// The working directory is set to the current working directory when the
+  /// reproducers are initialized. This method allows setting a different
+  /// working directory. This is used by the API test suite  which temporarily
+  /// changes the directory to where the test lives. This is a NO-OP in every
+  /// mode but capture.
+  static void SetWorkingDirectory(const char *path);
 };
 
 } // namespace lldb
Index: lldb/bindings/interface/SBReproducer.i
===
--- lldb/bindings/interface/SBReproducer.i
+++ lldb/bindings/interface/SBReproducer.i
@@ -13,5 +13,6 @@
 static const char *Capture(const char *path);
 static const char *PassiveReplay(const char *path);
 static bool SetAutoGenerate(bool b);
+static void SetWorkingDirectory(const char *path);
 };
 }


Index: lldb/source/API/SBReproducer.cpp
===
--- lldb/source/API/SBReproducer.cpp
+++ lldb/source/API/SBReproducer.cpp
@@ -231,6 +231,12 @@
   return path.c_str();
 }
 
+void SBReproducer::SetWorkingDirectory(const char *path) {
+  if (auto *g = lldb_private::repro::Reproducer::Instance().GetGenerator()) {
+g->GetOrCreate().Update(path);
+  }
+}
+
 char lldb_private::repro::SBProvider::ID = 0;
 const char *SBProvider::Info::name = "sbapi";
 const char *SBProvider::Info::file = "sbapi.bin";
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -526,6 +526,7 @@
 if traceAlways:
 print("Change dir to:", full_dir, file=sys.stderr)
 os.chdir(full_dir)
+lldb.SBReproducer.SetWorkingDirectory(full_dir)
 
 # Set platform context.
 cls.platformContext = lldbplatformutil.createPlatformContext()
Index: lldb/include/lldb/Utility/Reproducer.h
===
--- lldb/include/lldb/Utility/Reproducer.h
+++ lldb/include/lldb/Utility/Reproducer.h
@@ -147,6 +147,9 @@
   return;
 m_cwd = std::string(cwd.str());
   }
+
+  void Update(llvm::StringRef path) { m_cwd = 

[Lldb-commits] [PATCH] D79823: [lldb][Core] Remove dead codepath in Mangled

2020-05-12 Thread Alex Langford via Phabricator via lldb-commits
xiaobai created this revision.
xiaobai added reviewers: friss, JDevlieghere, shafik.
Herald added a project: LLDB.

Objective-C names are stored in m_demangled, not in m_mangled. The
method in the condition will never return true.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79823

Files:
  lldb/source/Core/Mangled.cpp


Index: lldb/source/Core/Mangled.cpp
===
--- lldb/source/Core/Mangled.cpp
+++ lldb/source/Core/Mangled.cpp
@@ -413,8 +413,6 @@
 const char *mangled_name = mangled.GetCString();
 if (CPlusPlusLanguage::IsCPPMangledName(mangled_name))
   return lldb::eLanguageTypeC_plus_plus;
-else if (ObjCLanguage::IsPossibleObjCMethodName(mangled_name))
-  return lldb::eLanguageTypeObjC;
   } else {
 // ObjC names aren't really mangled, so they won't necessarily be in the
 // mangled name slot.


Index: lldb/source/Core/Mangled.cpp
===
--- lldb/source/Core/Mangled.cpp
+++ lldb/source/Core/Mangled.cpp
@@ -413,8 +413,6 @@
 const char *mangled_name = mangled.GetCString();
 if (CPlusPlusLanguage::IsCPPMangledName(mangled_name))
   return lldb::eLanguageTypeC_plus_plus;
-else if (ObjCLanguage::IsPossibleObjCMethodName(mangled_name))
-  return lldb::eLanguageTypeObjC;
   } else {
 // ObjC names aren't really mangled, so they won't necessarily be in the
 // mangled name slot.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] ab22f71 - [lldb/Reproducers] Also record directories FileSystem::Collect.

2020-05-12 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-05-12T15:59:24-07:00
New Revision: ab22f71dd75895fbde1cd1a515b2164227d5dfd2

URL: 
https://github.com/llvm/llvm-project/commit/ab22f71dd75895fbde1cd1a515b2164227d5dfd2
DIFF: 
https://github.com/llvm/llvm-project/commit/ab22f71dd75895fbde1cd1a515b2164227d5dfd2.diff

LOG: [lldb/Reproducers] Also record directories FileSystem::Collect.

Now that the FileCollector knows how to deal with directories we no
longer have to ignore them in the FileSystem class.

Added: 


Modified: 
lldb/source/Host/common/FileSystem.cpp

Removed: 




diff  --git a/lldb/source/Host/common/FileSystem.cpp 
b/lldb/source/Host/common/FileSystem.cpp
index 7e33eeb2a812..0fa27d131e1a 100644
--- a/lldb/source/Host/common/FileSystem.cpp
+++ b/lldb/source/Host/common/FileSystem.cpp
@@ -487,7 +487,11 @@ void FileSystem::Collect(const FileSpec _spec) {
 }
 
 void FileSystem::Collect(const llvm::Twine ) {
-  if (m_collector && !llvm::sys::fs::is_directory(file)) {
+  if (!m_collector)
+return;
+
+  if (llvm::sys::fs::is_directory(file))
+m_collector->addDirectory(file);
+  else
 m_collector->addFile(file);
-  }
 }



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


[Lldb-commits] [PATCH] D79811: WIP: Reenable creation of artificial methods in AddMethodToCXXRecordType(...)

2020-05-12 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik created this revision.
shafik added reviewers: clayborg, jingham, aprantl, teemperor.
Herald added subscribers: kbarton, nemanjai.
shafik planned changes to this revision.
Herald added a subscriber: wuzish.
shafik requested review of this revision.
shafik retitled this revision from "Reenable creation of artificial methods in 
AddMethodToCXXRecordType(...)" to "WIP: Reenable creation of artificial methods 
in AddMethodToCXXRecordType(...)".
shafik added a comment.
shafik added a reviewer: labath.

I labeled this as WIP in progress since I expect some discussion and maybe a 
test case for which the change fails.


The framework for dealing with artificial methods is in place in 
`AddMethodToCXXRecordType(...)` but was gated by an early exit at some point.

This was due to implicit methods being emitted in some translations units but 
not others and then sometimes during import via the `ASTImporter` this would 
fail since they would no longer be structurally equivalent.

We have not been able to come up with a reproducer for the original issue and 
after fixing D79251  which was accidentally 
working the test suite passes with this change and we have cases that are 
broken without this change.


https://reviews.llvm.org/D79811

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
  lldb/test/API/lang/cpp/constructors/main.cpp


Index: lldb/test/API/lang/cpp/constructors/main.cpp
===
--- lldb/test/API/lang/cpp/constructors/main.cpp
+++ lldb/test/API/lang/cpp/constructors/main.cpp
@@ -1,5 +1,14 @@
+int flag=0;
+
+struct ClassForSideEffect {
+  ClassForSideEffect() { flag=1; }
+  ClassForSideEffect(int x) { flag=x; }
+};
+
 struct ClassWithImplicitCtor {
   int foo() { return 1; }
+  int x=10;
+  ClassForSideEffect cse = ClassForSideEffect(100);
 };
 
 struct ClassWithDefaultedCtor {
Index: lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
===
--- lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
+++ lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
@@ -18,6 +18,9 @@
 self.expect_expr("ClassWithDeletedCtor().value", result_type="int", 
result_value="6")
 self.expect_expr("ClassWithDeletedDefaultCtor(7).value", 
result_type="int", result_value="7")
 
+self.expect_expr("ClassWithImplicitCtor a{}; a.x", result_type="int", 
result_value="10")
+self.expect_expr("ClassWithImplicitCtor a{}; flag", result_type="int", 
result_value="100")
+
 # FIXME: It seems we try to call the non-existent default constructor 
here which is wrong.
 self.expect("expr ClassWithDefaultedCtor().foo()", error=True, 
substrs="Couldn't lookup symbols:")
 
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -7306,9 +7306,6 @@
   clang::CXXDestructorDecl *cxx_dtor_decl(nullptr);
   clang::CXXConstructorDecl *cxx_ctor_decl(nullptr);
 
-  if (is_artificial)
-return nullptr; // skip everything artificial
-
   const clang::ExplicitSpecifier explicit_spec(
   nullptr /*expr*/, is_explicit ? clang::ExplicitSpecKind::ResolvedTrue
 : clang::ExplicitSpecKind::ResolvedFalse);


Index: lldb/test/API/lang/cpp/constructors/main.cpp
===
--- lldb/test/API/lang/cpp/constructors/main.cpp
+++ lldb/test/API/lang/cpp/constructors/main.cpp
@@ -1,5 +1,14 @@
+int flag=0;
+
+struct ClassForSideEffect {
+  ClassForSideEffect() { flag=1; }
+  ClassForSideEffect(int x) { flag=x; }
+};
+
 struct ClassWithImplicitCtor {
   int foo() { return 1; }
+  int x=10;
+  ClassForSideEffect cse = ClassForSideEffect(100);
 };
 
 struct ClassWithDefaultedCtor {
Index: lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
===
--- lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
+++ lldb/test/API/lang/cpp/constructors/TestCppConstructors.py
@@ -18,6 +18,9 @@
 self.expect_expr("ClassWithDeletedCtor().value", result_type="int", result_value="6")
 self.expect_expr("ClassWithDeletedDefaultCtor(7).value", result_type="int", result_value="7")
 
+self.expect_expr("ClassWithImplicitCtor a{}; a.x", result_type="int", result_value="10")
+self.expect_expr("ClassWithImplicitCtor a{}; flag", result_type="int", result_value="100")
+
 # FIXME: It seems we try to call the non-existent default constructor here which is wrong.
 self.expect("expr ClassWithDefaultedCtor().foo()", error=True, substrs="Couldn't lookup symbols:")
 
Index: 

[Lldb-commits] [PATCH] D79811: WIP: Reenable creation of artificial methods in AddMethodToCXXRecordType(...)

2020-05-12 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added a comment.

I labeled this as WIP in progress since I expect some discussion and maybe a 
test case for which the change fails.


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

https://reviews.llvm.org/D79811



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


[Lldb-commits] [PATCH] D79654: [lldb/Driver] Support terminal resizing

2020-05-12 Thread Frederic Riss via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd9166ad27284: [lldb/Driver] Support terminal resizing 
(authored by friss).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79654

Files:
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Editline.h
  lldb/source/Core/Debugger.cpp
  lldb/source/Core/IOHandler.cpp
  lldb/source/Host/common/Editline.cpp
  lldb/test/API/iohandler/resize/TestIOHandlerResize.py

Index: lldb/test/API/iohandler/resize/TestIOHandlerResize.py
===
--- /dev/null
+++ lldb/test/API/iohandler/resize/TestIOHandlerResize.py
@@ -0,0 +1,36 @@
+"""
+Test resizing in our IOHandlers.
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+class IOHandlerCompletionTest(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+# PExpect uses many timeouts internally and doesn't play well
+# under ASAN on a loaded machine..
+@skipIfAsan
+@skipIfEditlineSupportMissing
+def test_resize(self):
+
+# Start with a small window
+self.launch(dimensions=(10,10))
+
+self.child.send("his is a long sentence missing its first letter.")
+
+# Now resize to something bigger
+self.child.setwinsize(100,500)
+
+# Hit "left" 60 times (to go to the beginning of the line) and insert
+# a character.
+self.child.send(60 * "\033[D")
+self.child.send("T")
+
+self.child.expect_exact("(lldb) This is a long sentence missing its first letter.")
+self.quit()
Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -560,6 +560,9 @@
 lldb::ConnectionStatus status = lldb::eConnectionStatusSuccess;
 char ch = 0;
 
+if (m_terminal_size_has_changed)
+  ApplyTerminalSizeChange();
+
 // This mutex is locked by our caller (GetLine). Unlock it while we read a
 // character (blocking operation), so we do not hold the mutex
 // indefinitely. This gives a chance for someone to interrupt us. After
@@ -1052,7 +1055,7 @@
 
   m_editline =
   el_init(m_editor_name.c_str(), m_input_file, m_output_file, m_error_file);
-  TerminalSizeChanged();
+  ApplyTerminalSizeChange();
 
   if (m_history_sp && m_history_sp->IsValid()) {
 if (!m_history_sp->Load()) {
@@ -1305,28 +1308,32 @@
   continuation_prompt == nullptr ? "" : continuation_prompt;
 }
 
-void Editline::TerminalSizeChanged() {
-  if (m_editline != nullptr) {
-el_resize(m_editline);
-int columns;
-// This function is documenting as taking (const char *, void *) for the
-// vararg part, but in reality in was consuming arguments until the first
-// null pointer. This was fixed in libedit in April 2019
-// ,
-// but we're keeping the workaround until a version with that fix is more
-// widely available.
-if (el_get(m_editline, EL_GETTC, "co", , nullptr) == 0) {
-  m_terminal_width = columns;
-  if (m_current_line_rows != -1) {
-const LineInfoW *info = el_wline(m_editline);
-int lineLength =
-(int)((info->lastchar - info->buffer) + GetPromptWidth());
-m_current_line_rows = (lineLength / columns) + 1;
-  }
-} else {
-  m_terminal_width = INT_MAX;
-  m_current_line_rows = 1;
+void Editline::TerminalSizeChanged() { m_terminal_size_has_changed = 1; }
+
+void Editline::ApplyTerminalSizeChange() {
+  if (!m_editline)
+return;
+
+  m_terminal_size_has_changed = 0;
+  el_resize(m_editline);
+  int columns;
+  // This function is documenting as taking (const char *, void *) for the
+  // vararg part, but in reality in was consuming arguments until the first
+  // null pointer. This was fixed in libedit in April 2019
+  // ,
+  // but we're keeping the workaround until a version with that fix is more
+  // widely available.
+  if (el_get(m_editline, EL_GETTC, "co", , nullptr) == 0) {
+m_terminal_width = columns;
+if (m_current_line_rows != -1) {
+  const LineInfoW *info = el_wline(m_editline);
+  int lineLength =
+  (int)((info->lastchar - info->buffer) + GetPromptWidth());
+  m_current_line_rows = (lineLength / columns) + 1;
 }
+  } else {
+m_terminal_width = INT_MAX;
+m_current_line_rows = 1;
   }
 }
 
Index: lldb/source/Core/IOHandler.cpp
===
--- lldb/source/Core/IOHandler.cpp
+++ lldb/source/Core/IOHandler.cpp
@@ -289,6 +289,12 @@
   

[Lldb-commits] [lldb] d9166ad - [lldb/Driver] Support terminal resizing

2020-05-12 Thread Fred Riss via lldb-commits

Author: Fred Riss
Date: 2020-05-12T11:55:25-07:00
New Revision: d9166ad272847e246799afbb5e0c71874f83aa12

URL: 
https://github.com/llvm/llvm-project/commit/d9166ad272847e246799afbb5e0c71874f83aa12
DIFF: 
https://github.com/llvm/llvm-project/commit/d9166ad272847e246799afbb5e0c71874f83aa12.diff

LOG: [lldb/Driver] Support terminal resizing

Summary:
The comment in the Editine.h header made it sound like editline was
just unable to handle terminal resizing. We were not ever telling
editline that the terminal had changed size, which might explain why
it wasn't working.

This patch threads a `TerminalSizeChanged()` callback through the
IOHandler and invokes it from the SIGWINCH handler in the driver. Our
`Editline` class already had a `TerminalSizeChanged()` method which
was invoked only when editline was configured.

This patch also changes `Editline` to not apply the changes right away
in `TerminalSizeChanged()`, but instead defer that to the next
character read. During my testing, it happened once that the signal
was received while our `ConnectionFileDescriptor::Read` was allocating
memory. As `el_resize` seems to allocate memory too, this crashed.

Reviewers: labath, teemperor

Subscribers: lldb-commits

Tags: #lldb

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

Added: 
lldb/test/API/iohandler/resize/TestIOHandlerResize.py

Modified: 
lldb/include/lldb/Core/IOHandler.h
lldb/include/lldb/Host/Editline.h
lldb/source/Core/Debugger.cpp
lldb/source/Core/IOHandler.cpp
lldb/source/Host/common/Editline.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/IOHandler.h 
b/lldb/include/lldb/Core/IOHandler.h
index ff75bfb15cfb..539ba04ab84c 100644
--- a/lldb/include/lldb/Core/IOHandler.h
+++ b/lldb/include/lldb/Core/IOHandler.h
@@ -95,6 +95,8 @@ class IOHandler {
 
   virtual void Deactivate() { m_active = false; }
 
+  virtual void TerminalSizeChanged() {}
+
   virtual const char *GetPrompt() {
 // Prompt support isn't mandatory
 return nullptr;
@@ -369,6 +371,8 @@ class IOHandlerEditline : public IOHandler {
 
   void Deactivate() override;
 
+  void TerminalSizeChanged() override;
+
   ConstString GetControlSequence(char ch) override {
 return m_delegate.IOHandlerGetControlSequence(ch);
   }

diff  --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h
index 6590a1603bf0..6e9daae42217 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -19,13 +19,10 @@
 //good amount of the text will
 //disappear.  It's still in the buffer, just invisible.
 // b) The prompt printing logic for dealing with ANSI formatting characters is
-// broken, which is why we're
-//working around it here.
-// c) When resizing the terminal window, if the cursor moves between rows
-// libedit will get confused. d) The incremental search uses escape to cancel
-// input, so it's confused by
+// broken, which is why we're working around it here.
+// c) The incremental search uses escape to cancel input, so it's confused by
 // ANSI sequences starting with escape.
-// e) Emoji support is fairly terrible, presumably it doesn't understand
+// d) Emoji support is fairly terrible, presumably it doesn't understand
 // composed characters?
 
 #ifndef LLDB_HOST_EDITLINE_H
@@ -50,6 +47,7 @@
 #include 
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -171,9 +169,7 @@ class Editline {
   /// editing scenarios.
   void SetContinuationPrompt(const char *continuation_prompt);
 
-  /// Required to update the width of the terminal registered for I/O.  It is
-  /// critical that this
-  /// be correct at all times.
+  /// Call when the terminal size changes
   void TerminalSizeChanged();
 
   /// Returns the prompt established by SetPrompt()
@@ -328,6 +324,8 @@ class Editline {
 
   bool CompleteCharacter(char ch, EditLineGetCharType );
 
+  void ApplyTerminalSizeChange();
+
 private:
 #if LLDB_EDITLINE_USE_WCHAR
   std::wstring_convert> m_utf8conv;
@@ -350,6 +348,7 @@ class Editline {
   std::string m_set_continuation_prompt;
   std::string m_current_prompt;
   bool m_needs_prompt_repaint = false;
+  volatile std::sig_atomic_t m_terminal_size_has_changed = 0;
   std::string m_editor_name;
   FILE *m_input_file;
   FILE *m_output_file;

diff  --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 1d4bf0dafb72..546dc9e86e7d 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -315,6 +315,9 @@ uint32_t Debugger::GetTerminalWidth() const {
 }
 
 bool Debugger::SetTerminalWidth(uint32_t term_width) {
+  if (auto handler_sp = m_io_handler_stack.Top())
+handler_sp->TerminalSizeChanged();
+
   const uint32_t idx = ePropertyTerminalWidth;
   return m_collection_sp->SetPropertyAtIndexAsSInt64(nullptr, idx, term_width);
 }

diff  --git a/lldb/source/Core/IOHandler.cpp b/lldb/source/Core/IOHandler.cpp
index 

[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread António Afonso via Phabricator via lldb-commits
aadsm marked an inline comment as done.
aadsm added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py:250-251
 def cleanup():
-self.vscode.request_disconnect(terminateDebuggee=True)
+if disconnect:
+self.vscode.request_disconnect(terminateDebuggee=True)
 self.vscode.terminate()

labath wrote:
> aadsm wrote:
> > labath wrote:
> > > What's the purpose of this argument? To ensure a clean shutdown? Would it 
> > > be possible to make the function smart enough to detect the right thing 
> > > to do when cleaning up?
> > it indicates if the process should be killed or not when lldb-vscode 
> > disconnects from it.
> I meant the `disconnect` argument to the `attach` function in the test suite 
> , not the `terminateDebuggee` argument of the `disconnect` command to 
> lldb-vscode.
> 
> My point is that, given the way the cleanup functions work, you cannot assume 
> that you're going to be invoked in any particular moment. For example they 
> can called if an assertion fails, to ensure any external resources/processes 
> are terminated. Since you don't know which assertion will fail, it's best if 
> you don't assume anything about the the state of the inferior and just do 
> your best to clean up. I'm not sure what "doing your best" would mean here. 
> For example it may mean sending a "terminate" request and ignoring errors. Or 
> maybe a better solution is possible...
oh yeah of course, the argument I added . Oh, you know what, I misread when 
the cleanup function was going to be called. I don't need this at all, will 
remove it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [PATCH] D79789: [lldb] Don't dissasemble large functions by default

2020-05-12 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

Instead of just printing out the range, can we print out the disassemble 
command you would run to actually disassemble the range?

Also, I think we should add a --force option since if you were using this in a 
script you wouldn't get a chance to respond to the error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79789



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


[Lldb-commits] [PATCH] D79646: [Reproducers] Serialize process arguments in ProcessInfo

2020-05-12 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbad61548b207: [Reproducers] Serialize process arguments in 
ProcessInfo (authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79646

Files:
  lldb/include/lldb/Utility/Args.h
  lldb/source/Utility/Args.cpp
  lldb/source/Utility/ProcessInfo.cpp
  lldb/test/Shell/Reproducer/TestProcessList.test
  lldb/unittests/Utility/ArgsTest.cpp

Index: lldb/unittests/Utility/ArgsTest.cpp
===
--- lldb/unittests/Utility/ArgsTest.cpp
+++ lldb/unittests/Utility/ArgsTest.cpp
@@ -282,3 +282,34 @@
   EXPECT_EQ(3u, args.GetArgumentCount());
   EXPECT_STREQ(args.GetArgumentAtIndex(2), "b");
 }
+
+TEST(ArgsTest, Yaml) {
+  std::string buffer;
+  llvm::raw_string_ostream os(buffer);
+
+  // Serialize.
+  Args args;
+  args.SetCommandString("this 'has' \"multiple\" args");
+  llvm::yaml::Output yout(os);
+  yout << args;
+  os.flush();
+
+  llvm::outs() << buffer;
+
+  // Deserialize.
+  Args deserialized;
+  llvm::yaml::Input yin(buffer);
+  yin >> deserialized;
+
+  EXPECT_EQ(4u, deserialized.GetArgumentCount());
+  EXPECT_STREQ(deserialized.GetArgumentAtIndex(0), "this");
+  EXPECT_STREQ(deserialized.GetArgumentAtIndex(1), "has");
+  EXPECT_STREQ(deserialized.GetArgumentAtIndex(2), "multiple");
+  EXPECT_STREQ(deserialized.GetArgumentAtIndex(3), "args");
+
+  llvm::ArrayRef entries = deserialized.entries();
+  EXPECT_EQ(entries[0].GetQuoteChar(), '\0');
+  EXPECT_EQ(entries[1].GetQuoteChar(), '\'');
+  EXPECT_EQ(entries[2].GetQuoteChar(), '"');
+  EXPECT_EQ(entries[3].GetQuoteChar(), '\0');
+}
Index: lldb/test/Shell/Reproducer/TestProcessList.test
===
--- /dev/null
+++ lldb/test/Shell/Reproducer/TestProcessList.test
@@ -0,0 +1,21 @@
+# UNSUPPORTED: system-freebsd
+
+# Test that ProcessInfo is correctly serialized by comparing the output of
+# 'platform process list -v' during capture and replay. The test assumes that
+# there's at least two processes.
+
+# RUN: %lldb -x -b -o 'platform process list -v' -o 'reproducer generate' --capture --capture-path %t.repro > %t.log
+# RUN: %lldb --replay %t.repro >> %t.log
+# RUN: cat %t.log | FileCheck %s
+
+# CHECK: [[PROCS:[0-9]+]] matching processes were found
+# CHECK: PIDPARENT USER   GROUP  EFF USER   EFF GROUP  TRIPLE ARGUMENTS
+# CHECK-NEXT: == == == == == == == 
+# CHECK-NEXT: [[PID0:[0-9]+]] [[PROC0:.*]]
+# CHECK-NEXT: [[PID1:[0-9]+]] [[PROC1:.*]]
+# CHECK: Reproducer written to
+# CHECK: [[PROCS]] matching processes were found
+# CHECK: PIDPARENT USER   GROUP  EFF USER   EFF GROUP  TRIPLE ARGUMENTS
+# CHECK-NEXT: == == == == == == == 
+# CHECK-NEXT: [[PID0]] [[PROC0]]
+# CHECK-NEXT: [[PID1]] [[PROC1]]
Index: lldb/source/Utility/ProcessInfo.cpp
===
--- lldb/source/Utility/ProcessInfo.cpp
+++ lldb/source/Utility/ProcessInfo.cpp
@@ -337,6 +337,7 @@
 IO , ProcessInstanceInfo ) {
   io.mapRequired("executable", Info.m_executable);
   io.mapRequired("arg0", Info.m_arg0);
+  io.mapRequired("args", Info.m_arguments);
   io.mapRequired("arch", Info.m_arch);
   io.mapRequired("uid", Info.m_uid);
   io.mapRequired("gid", Info.m_gid);
Index: lldb/source/Utility/Args.cpp
===
--- lldb/source/Utility/Args.cpp
+++ lldb/source/Utility/Args.cpp
@@ -684,3 +684,20 @@
 m_suffix = std::string(original_args);
   }
 }
+
+void llvm::yaml::MappingTraits::mapping(IO ,
+Args::ArgEntry ) {
+  MappingNormalization keys(io, v);
+  io.mapRequired("value", keys->value);
+  io.mapRequired("quote", keys->quote);
+}
+
+void llvm::yaml::MappingTraits::mapping(IO , Args ) {
+  io.mapRequired("entries", v.m_entries);
+
+  // Recompute m_argv vector.
+  v.m_argv.clear();
+  for (auto  : v.m_entries)
+v.m_argv.push_back(entry.data());
+  v.m_argv.push_back(nullptr);
+}
Index: lldb/include/lldb/Utility/Args.h
===
--- lldb/include/lldb/Utility/Args.h
+++ lldb/include/lldb/Utility/Args.h
@@ -14,6 +14,7 @@
 #include "lldb/lldb-types.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/YAMLTraits.h"
 #include 
 #include 
 #include 
@@ -34,6 +35,9 @@
   struct ArgEntry {
   private:
 friend class Args;
+friend struct llvm::yaml::MappingTraits;
+friend struct llvm::yaml::MappingTraits;
+
 std::unique_ptr ptr;

[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Mathias LANG via Phabricator via lldb-commits
Geod24 updated this revision to Diff 263477.
Geod24 added a comment.

Merge whitespace-removing commit into the main one

Since I can't seem to get arc to comply.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll

Index: lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
@@ -0,0 +1,73 @@
+;
+; This test verifies that DWARF DIE of type DW_TAG_basic_type with DW_ATE_UTF
+; are matched based on their bit size (8, 16, 32) in addition to their name.
+;
+; This is used by languages which don't use the C(++) naming of
+; `char{8,16,32}_t`, e.g. the D programming language uses `char`, `wchar`, `dchar`.
+;
+; The D code used to generate this IR is:
+; ```
+; // Compiled with `ldc2 --mtriple=x86_64-pc-linux -betterC -g -c --output-ll utftypes.d`
+; __gshared string utf8 = "Hello";
+; __gshared wstring utf16 = "Dlang"w;
+; __gshared dstring utf32 = "World"d;
+; ```
+;
+; Note: lldb will print types differently before and after 'run'.
+;
+; RUN: %clang --target=x86_64-pc-linu -c -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s
+;
+; CHECK: struct string {
+; CHECK: unsigned long length;
+; CHECK: char8_t *ptr;
+; CHECK: }
+
+$_D8utftypes4utf8Aya = comdat any
+$_D8utftypes5utf16Ayu = comdat any
+$_D8utftypes5utf32Ayw = comdat any
+
+@_D8utftypes4utf8Aya = global { i64, i8* } { i64 5, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str, i32 0, i32 0) }, comdat, align 8, !dbg !0 ; [#uses = 0]
+@.str = private unnamed_addr constant [6 x i8] c"Hello\00" ; [#uses = 1]
+@_D8utftypes5utf16Ayu = global { i64, i16* } { i64 5, i16* getelementptr inbounds ([6 x i16], [6 x i16]* @.str.1, i32 0, i32 0) }, comdat, align 8, !dbg !11 ; [#uses = 0]
+@.str.1 = private unnamed_addr constant [6 x i16] [i16 68, i16 108, i16 97, i16 110, i16 103, i16 0] ; [#uses = 1]
+@_D8utftypes5utf32Ayw = global { i64, i32* } { i64 5, i32* getelementptr inbounds ([6 x i32], [6 x i32]* @.str.2, i32 0, i32 0) }, comdat, align 8, !dbg !18 ; [#uses = 0]
+@.str.2 = private unnamed_addr constant [6 x i32] [i32 87, i32 111, i32 114, i32 108, i32 100, i32 0] ; [#uses = 1]
+
+!llvm.module.flags = !{!25}
+!llvm.dbg.cu = !{!26}
+!llvm.ident = !{!32}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "utf8", linkageName: "_D8utftypes4utf8Aya", scope: !2, file: !3, line: 1, type: !4, isLocal: false, isDefinition: true)
+!2 = !DIModule(scope: null, name: "utftypes")
+!3 = !DIFile(filename: "utftypes.d", directory: "/tmp")
+!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "string", file: !3, size: 128, align: 64, elements: !5, identifier: "Aya")
+!5 = !{!6, !8}
+!6 = !DIDerivedType(tag: DW_TAG_member, name: "length", file: !3, baseType: !7, size: 64, align: 64, flags: DIFlagPublic)
+!7 = !DIBasicType(name: "ulong", size: 64, encoding: DW_ATE_unsigned)
+!8 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !9, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(char)*", baseType: !10, size: 64, align: 64)
+!10 = !DIBasicType(name: "immutable(char)", size: 8, encoding: DW_ATE_UTF)
+!11 = !DIGlobalVariableExpression(var: !12, expr: !DIExpression())
+!12 = distinct !DIGlobalVariable(name: "utf16", linkageName: "_D8utftypes5utf16Ayu", scope: !2, file: !3, line: 2, type: !13, isLocal: false, isDefinition: true)
+!13 = !DICompositeType(tag: DW_TAG_structure_type, name: "wstring", file: !3, size: 128, align: 64, elements: !14, identifier: "Ayu")
+!14 = !{!6, !15}
+!15 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !16, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(wchar)*", baseType: !17, size: 64, align: 64)
+!17 = !DIBasicType(name: "immutable(wchar)", size: 16, encoding: DW_ATE_UTF)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = distinct !DIGlobalVariable(name: "utf32", linkageName: "_D8utftypes5utf32Ayw", scope: !2, file: !3, line: 3, type: !20, isLocal: false, isDefinition: true)
+!20 = !DICompositeType(tag: DW_TAG_structure_type, name: "dstring", file: !3, size: 128, align: 64, elements: !21, identifier: "Ayw")
+!21 = !{!6, !22}
+!22 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !23, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!23 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(dchar)*", baseType: !24, size: 64, align: 64)
+!24 = !DIBasicType(name: "immutable(dchar)", size: 32, encoding: DW_ATE_UTF)
+!25 = !{i32 2, !"Debug 

[Lldb-commits] [PATCH] D79789: [lldb] Don't dissasemble large functions by default

2020-05-12 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

Looks good to me.




Comment at: lldb/source/Commands/CommandObjectDisassemble.cpp:225
+ Address::DumpStyleFileAddress);
+  msg << ". To disassemble, specify an instruction count limit, or start/stop "
+ "addresses.";

nit: I don't think we need either of these commas. 



Comment at: lldb/test/Shell/Commands/command-disassemble-process.yaml:93
 Value:   0x4002
-Size:0x0008
+Size:[[MAIN_SIZE]]
 ProgramHeaders:

Cool, I didn't realize this was possible. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79789



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


[Lldb-commits] [lldb] bad6154 - [Reproducers] Serialize process arguments in ProcessInfo

2020-05-12 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-05-12T11:12:37-07:00
New Revision: bad61548b2074cf3bf7be2cb4c0d75646e001a73

URL: 
https://github.com/llvm/llvm-project/commit/bad61548b2074cf3bf7be2cb4c0d75646e001a73
DIFF: 
https://github.com/llvm/llvm-project/commit/bad61548b2074cf3bf7be2cb4c0d75646e001a73.diff

LOG: [Reproducers] Serialize process arguments in ProcessInfo

While debugging why TestProcessList.py failed during passive replay, I
remembered that we don't serialize the arguments for ProcessInfo. This
is necessary to make the test pass and to make platform process list -v
behave the same during capture and replay.

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

Added: 
lldb/test/Shell/Reproducer/TestProcessList.test

Modified: 
lldb/include/lldb/Utility/Args.h
lldb/source/Utility/Args.cpp
lldb/source/Utility/ProcessInfo.cpp
lldb/unittests/Utility/ArgsTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Args.h 
b/lldb/include/lldb/Utility/Args.h
index 1308f4038dbd..560f25795d3b 100644
--- a/lldb/include/lldb/Utility/Args.h
+++ b/lldb/include/lldb/Utility/Args.h
@@ -14,6 +14,7 @@
 #include "lldb/lldb-types.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/YAMLTraits.h"
 #include 
 #include 
 #include 
@@ -34,6 +35,9 @@ class Args {
   struct ArgEntry {
   private:
 friend class Args;
+friend struct llvm::yaml::MappingTraits;
+friend struct llvm::yaml::MappingTraits;
+
 std::unique_ptr ptr;
 char quote;
 
@@ -283,6 +287,8 @@ class Args {
char quote_char);
 
 private:
+  friend struct llvm::yaml::MappingTraits;
+
   std::vector m_entries;
   std::vector m_argv;
 };
@@ -373,4 +379,28 @@ class OptionsWithRaw {
 
 } // namespace lldb_private
 
+namespace llvm {
+namespace yaml {
+template <> struct MappingTraits {
+  class NormalizedArgEntry {
+  public:
+NormalizedArgEntry(IO &) {}
+NormalizedArgEntry(IO &, lldb_private::Args::ArgEntry )
+: value(entry.ref()), quote(entry.quote) {}
+lldb_private::Args::ArgEntry denormalize(IO &) {
+  return lldb_private::Args::ArgEntry(value, quote);
+}
+StringRef value;
+char quote;
+  };
+  static void mapping(IO , lldb_private::Args::ArgEntry );
+};
+template <> struct MappingTraits {
+  static void mapping(IO , lldb_private::Args );
+};
+} // namespace yaml
+} // namespace llvm
+
+LLVM_YAML_IS_SEQUENCE_VECTOR(lldb_private::Args::ArgEntry)
+
 #endif // LLDB_UTILITY_ARGS_H

diff  --git a/lldb/source/Utility/Args.cpp b/lldb/source/Utility/Args.cpp
index 443f9bf37cc4..27dcbb822910 100644
--- a/lldb/source/Utility/Args.cpp
+++ b/lldb/source/Utility/Args.cpp
@@ -684,3 +684,20 @@ void OptionsWithRaw::SetFromString(llvm::StringRef 
arg_string) {
 m_suffix = std::string(original_args);
   }
 }
+
+void llvm::yaml::MappingTraits::mapping(IO ,
+Args::ArgEntry ) {
+  MappingNormalization keys(io, v);
+  io.mapRequired("value", keys->value);
+  io.mapRequired("quote", keys->quote);
+}
+
+void llvm::yaml::MappingTraits::mapping(IO , Args ) {
+  io.mapRequired("entries", v.m_entries);
+
+  // Recompute m_argv vector.
+  v.m_argv.clear();
+  for (auto  : v.m_entries)
+v.m_argv.push_back(entry.data());
+  v.m_argv.push_back(nullptr);
+}

diff  --git a/lldb/source/Utility/ProcessInfo.cpp 
b/lldb/source/Utility/ProcessInfo.cpp
index 9a29218f7f1d..aae48d6a4872 100644
--- a/lldb/source/Utility/ProcessInfo.cpp
+++ b/lldb/source/Utility/ProcessInfo.cpp
@@ -337,6 +337,7 @@ void 
llvm::yaml::MappingTraits::mapping(
 IO , ProcessInstanceInfo ) {
   io.mapRequired("executable", Info.m_executable);
   io.mapRequired("arg0", Info.m_arg0);
+  io.mapRequired("args", Info.m_arguments);
   io.mapRequired("arch", Info.m_arch);
   io.mapRequired("uid", Info.m_uid);
   io.mapRequired("gid", Info.m_gid);

diff  --git a/lldb/test/Shell/Reproducer/TestProcessList.test 
b/lldb/test/Shell/Reproducer/TestProcessList.test
new file mode 100644
index ..200dcb3febe7
--- /dev/null
+++ b/lldb/test/Shell/Reproducer/TestProcessList.test
@@ -0,0 +1,21 @@
+# UNSUPPORTED: system-freebsd
+
+# Test that ProcessInfo is correctly serialized by comparing the output of
+# 'platform process list -v' during capture and replay. The test assumes that
+# there's at least two processes.
+
+# RUN: %lldb -x -b -o 'platform process list -v' -o 'reproducer generate' 
--capture --capture-path %t.repro > %t.log
+# RUN: %lldb --replay %t.repro >> %t.log
+# RUN: cat %t.log | FileCheck %s
+
+# CHECK: [[PROCS:[0-9]+]] matching processes were found
+# CHECK: PIDPARENT USER   GROUP  EFF USER   EFF GROUP  TRIPLE  
   ARGUMENTS
+# CHECK-NEXT: == == == == == == 
== 
+# CHECK-NEXT: 

[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py:250-251
 def cleanup():
-self.vscode.request_disconnect(terminateDebuggee=True)
+if disconnect:
+self.vscode.request_disconnect(terminateDebuggee=True)
 self.vscode.terminate()

aadsm wrote:
> labath wrote:
> > What's the purpose of this argument? To ensure a clean shutdown? Would it 
> > be possible to make the function smart enough to detect the right thing to 
> > do when cleaning up?
> it indicates if the process should be killed or not when lldb-vscode 
> disconnects from it.
I meant the `disconnect` argument to the `attach` function in the test suite , 
not the `terminateDebuggee` argument of the `disconnect` command to lldb-vscode.

My point is that, given the way the cleanup functions work, you cannot assume 
that you're going to be invoked in any particular moment. For example they can 
called if an assertion fails, to ensure any external resources/processes are 
terminated. Since you don't know which assertion will fail, it's best if you 
don't assume anything about the the state of the inferior and just do your best 
to clean up. I'm not sure what "doing your best" would mean here. For example 
it may mean sending a "terminate" request and ignoring errors. Or maybe a 
better solution is possible...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Mathias LANG via Phabricator via lldb-commits
Geod24 updated this revision to Diff 263463.
Geod24 added a comment.

Add missing commit

See previous diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll

Index: lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
@@ -0,0 +1,73 @@
+;
+; This test verifies that DWARF DIE of type DW_TAG_basic_type with DW_ATE_UTF
+; are matched based on their bit size (8, 16, 32) in addition to their name.
+;
+; This is used by languages which don't use the C(++) naming of
+; `char{8,16,32}_t`, e.g. the D programming language uses `char`, `wchar`, `dchar`.
+;
+; The D code used to generate this IR is:
+; ```
+; // Compiled with `ldc2 --mtriple=x86_64-pc-linux -betterC -g -c --output-ll utftypes.d`
+; __gshared string utf8 = "Hello";
+; __gshared wstring utf16 = "Dlang"w;
+; __gshared dstring utf32 = "World"d;
+; ```
+;
+; Note: lldb will print types differently before and after 'run'.
+;
+; RUN: %clang --target=x86_64-pc-linu -c -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s
+;
+; CHECK: struct string {
+; CHECK: unsigned long length;
+; CHECK: char8_t *ptr;
+; CHECK: }
+
+$_D8utftypes4utf8Aya = comdat any
+$_D8utftypes5utf16Ayu = comdat any
+$_D8utftypes5utf32Ayw = comdat any
+
+@_D8utftypes4utf8Aya = global { i64, i8* } { i64 5, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str, i32 0, i32 0) }, comdat, align 8, !dbg !0 ; [#uses = 0]
+@.str = private unnamed_addr constant [6 x i8] c"Hello\00" ; [#uses = 1]
+@_D8utftypes5utf16Ayu = global { i64, i16* } { i64 5, i16* getelementptr inbounds ([6 x i16], [6 x i16]* @.str.1, i32 0, i32 0) }, comdat, align 8, !dbg !11 ; [#uses = 0]
+@.str.1 = private unnamed_addr constant [6 x i16] [i16 68, i16 108, i16 97, i16 110, i16 103, i16 0] ; [#uses = 1]
+@_D8utftypes5utf32Ayw = global { i64, i32* } { i64 5, i32* getelementptr inbounds ([6 x i32], [6 x i32]* @.str.2, i32 0, i32 0) }, comdat, align 8, !dbg !18 ; [#uses = 0]
+@.str.2 = private unnamed_addr constant [6 x i32] [i32 87, i32 111, i32 114, i32 108, i32 100, i32 0] ; [#uses = 1]
+
+!llvm.module.flags = !{!25}
+!llvm.dbg.cu = !{!26}
+!llvm.ident = !{!32}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "utf8", linkageName: "_D8utftypes4utf8Aya", scope: !2, file: !3, line: 1, type: !4, isLocal: false, isDefinition: true)
+!2 = !DIModule(scope: null, name: "utftypes")
+!3 = !DIFile(filename: "utftypes.d", directory: "/tmp")
+!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "string", file: !3, size: 128, align: 64, elements: !5, identifier: "Aya")
+!5 = !{!6, !8}
+!6 = !DIDerivedType(tag: DW_TAG_member, name: "length", file: !3, baseType: !7, size: 64, align: 64, flags: DIFlagPublic)
+!7 = !DIBasicType(name: "ulong", size: 64, encoding: DW_ATE_unsigned)
+!8 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !9, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(char)*", baseType: !10, size: 64, align: 64)
+!10 = !DIBasicType(name: "immutable(char)", size: 8, encoding: DW_ATE_UTF)
+!11 = !DIGlobalVariableExpression(var: !12, expr: !DIExpression())
+!12 = distinct !DIGlobalVariable(name: "utf16", linkageName: "_D8utftypes5utf16Ayu", scope: !2, file: !3, line: 2, type: !13, isLocal: false, isDefinition: true)
+!13 = !DICompositeType(tag: DW_TAG_structure_type, name: "wstring", file: !3, size: 128, align: 64, elements: !14, identifier: "Ayu")
+!14 = !{!6, !15}
+!15 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !16, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(wchar)*", baseType: !17, size: 64, align: 64)
+!17 = !DIBasicType(name: "immutable(wchar)", size: 16, encoding: DW_ATE_UTF)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = distinct !DIGlobalVariable(name: "utf32", linkageName: "_D8utftypes5utf32Ayw", scope: !2, file: !3, line: 3, type: !20, isLocal: false, isDefinition: true)
+!20 = !DICompositeType(tag: DW_TAG_structure_type, name: "dstring", file: !3, size: 128, align: 64, elements: !21, identifier: "Ayw")
+!21 = !{!6, !22}
+!22 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !23, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!23 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(dchar)*", baseType: !24, size: 64, align: 64)
+!24 = !DIBasicType(name: "immutable(dchar)", size: 32, encoding: DW_ATE_UTF)
+!25 = !{i32 2, !"Debug Info Version", i32 3}
+!26 = distinct 

[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread António Afonso via Phabricator via lldb-commits
aadsm marked 2 inline comments as done.
aadsm added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py:250-251
 def cleanup():
-self.vscode.request_disconnect(terminateDebuggee=True)
+if disconnect:
+self.vscode.request_disconnect(terminateDebuggee=True)
 self.vscode.terminate()

labath wrote:
> What's the purpose of this argument? To ensure a clean shutdown? Would it be 
> possible to make the function smart enough to detect the right thing to do 
> when cleaning up?
it indicates if the process should be killed or not when lldb-vscode 
disconnects from it.



Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:777
   auto state = process.GetState();
-
+  g_vsc.RunTerminateCommands();
   switch (state) {

labath wrote:
> How about moving this to line ~801 so that it is sent *after* the inferior is 
> killed, similar to how you above perform the commands after receiving the 
> exit event?
yap, that does make sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Mathias LANG via Phabricator via lldb-commits
Geod24 updated this revision to Diff 263462.
Geod24 added a comment.

Remove a trailing whitespace in TypeSystemClang.cpp

The pre-merge checks are apparently failing, and from what I can gather from 
the logs,
it seems to be because of a whitespace issue:

  [2020-05-12T16:19:00.309Z] + clang-tidy-diff -p1 -quiet
  [2020-05-12T16:19:00.309Z] + sed '/^[[:space:]]*$/d'
  [2020-05-12T16:19:03.616Z] 972 warnings and 1 error generated.
  [2020-05-12T16:19:03.616Z] Error while processing 
[...]/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp.

Since there was a trailing whitespace in that file, I added an extra commit to 
remove it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll

Index: lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
@@ -0,0 +1,73 @@
+;
+; This test verifies that DWARF DIE of type DW_TAG_basic_type with DW_ATE_UTF
+; are matched based on their bit size (8, 16, 32) in addition to their name.
+;
+; This is used by languages which don't use the C(++) naming of
+; `char{8,16,32}_t`, e.g. the D programming language uses `char`, `wchar`, `dchar`.
+;
+; The D code used to generate this IR is:
+; ```
+; // Compiled with `ldc2 --mtriple=x86_64-pc-linux -betterC -g -c --output-ll utftypes.d`
+; __gshared string utf8 = "Hello";
+; __gshared wstring utf16 = "Dlang"w;
+; __gshared dstring utf32 = "World"d;
+; ```
+;
+; Note: lldb will print types differently before and after 'run'.
+;
+; RUN: %clang --target=x86_64-pc-linu -c -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s
+;
+; CHECK: struct string {
+; CHECK: unsigned long length;
+; CHECK: char8_t *ptr;
+; CHECK: }
+
+$_D8utftypes4utf8Aya = comdat any
+$_D8utftypes5utf16Ayu = comdat any
+$_D8utftypes5utf32Ayw = comdat any
+
+@_D8utftypes4utf8Aya = global { i64, i8* } { i64 5, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str, i32 0, i32 0) }, comdat, align 8, !dbg !0 ; [#uses = 0]
+@.str = private unnamed_addr constant [6 x i8] c"Hello\00" ; [#uses = 1]
+@_D8utftypes5utf16Ayu = global { i64, i16* } { i64 5, i16* getelementptr inbounds ([6 x i16], [6 x i16]* @.str.1, i32 0, i32 0) }, comdat, align 8, !dbg !11 ; [#uses = 0]
+@.str.1 = private unnamed_addr constant [6 x i16] [i16 68, i16 108, i16 97, i16 110, i16 103, i16 0] ; [#uses = 1]
+@_D8utftypes5utf32Ayw = global { i64, i32* } { i64 5, i32* getelementptr inbounds ([6 x i32], [6 x i32]* @.str.2, i32 0, i32 0) }, comdat, align 8, !dbg !18 ; [#uses = 0]
+@.str.2 = private unnamed_addr constant [6 x i32] [i32 87, i32 111, i32 114, i32 108, i32 100, i32 0] ; [#uses = 1]
+
+!llvm.module.flags = !{!25}
+!llvm.dbg.cu = !{!26}
+!llvm.ident = !{!32}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "utf8", linkageName: "_D8utftypes4utf8Aya", scope: !2, file: !3, line: 1, type: !4, isLocal: false, isDefinition: true)
+!2 = !DIModule(scope: null, name: "utftypes")
+!3 = !DIFile(filename: "utftypes.d", directory: "/tmp")
+!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "string", file: !3, size: 128, align: 64, elements: !5, identifier: "Aya")
+!5 = !{!6, !8}
+!6 = !DIDerivedType(tag: DW_TAG_member, name: "length", file: !3, baseType: !7, size: 64, align: 64, flags: DIFlagPublic)
+!7 = !DIBasicType(name: "ulong", size: 64, encoding: DW_ATE_unsigned)
+!8 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !9, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(char)*", baseType: !10, size: 64, align: 64)
+!10 = !DIBasicType(name: "immutable(char)", size: 8, encoding: DW_ATE_UTF)
+!11 = !DIGlobalVariableExpression(var: !12, expr: !DIExpression())
+!12 = distinct !DIGlobalVariable(name: "utf16", linkageName: "_D8utftypes5utf16Ayu", scope: !2, file: !3, line: 2, type: !13, isLocal: false, isDefinition: true)
+!13 = !DICompositeType(tag: DW_TAG_structure_type, name: "wstring", file: !3, size: 128, align: 64, elements: !14, identifier: "Ayu")
+!14 = !{!6, !15}
+!15 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !16, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(wchar)*", baseType: !17, size: 64, align: 64)
+!17 = !DIBasicType(name: "immutable(wchar)", size: 16, encoding: DW_ATE_UTF)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = distinct !DIGlobalVariable(name: "utf32", linkageName: "_D8utftypes5utf32Ayw", scope: !2, file: !3, line: 3, type: !20, isLocal: false, isDefinition: true)
+!20 = 

[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread António Afonso via Phabricator via lldb-commits
aadsm added a comment.

> I gotta say I don't understand the difference between "exit" and "terminate" 
> commands, as both seem to happen pretty at once. Is the difference that 
> "exit" commands are run only when the inferior exits freely on its own, and 
> not when we forcefully kill it? And that "terminate" cmds are run in both 
> cases?

Yeah, just like said, the exit event (and commands) only happen when the 
program normally exits (with an exit code). However, I want to run commands 
when the debugging session is over, which might not necessarily mean the 
debuggee has ended (forcefully or not), only that we stopped debugging it. My 
main goal is to collect stats of the debugging session that has just ended.

> If you say that they are useful, then sure, I don't see a reason to not do 
> this, though it seems to me like this will be confusing, and would be worth 
> documenting somewhere. Maybe in that json file (I forgot where it's stored) 
> which defines the protocol extensions used by lldb-vscode?

Ah yes, I'll add that to the package.json definition of the extension and also 
the README.md.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [PATCH] D79447: [Debug][CodeView] Emit fully qualified names for globals

2020-05-12 Thread Alexandre Ganea via Phabricator via lldb-commits
aganea reopened this revision.
aganea added a comment.
This revision is now accepted and ready to land.

Could you please take another look? Thank you in advance!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79447



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


[Lldb-commits] [PATCH] D79447: [Debug][CodeView] Emit fully qualified names for globals

2020-05-12 Thread Alexandre Ganea via Phabricator via lldb-commits
aganea updated this revision to Diff 263450.
aganea added a comment.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Reopening because I had to revert.

- Fix lldb's variables.test
- Fix type lowering, as described here: D79512 
- Added assert in `emitDebugInfoForUDTs` to ensure no lowering can occur during 
UDT emission, as suggested by @rnk


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79447

Files:
  lldb/test/Shell/SymbolFile/PDB/variables.test
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
  llvm/test/DebugInfo/COFF/global-constants.ll
  llvm/test/DebugInfo/COFF/global_visibility.ll
  llvm/test/DebugInfo/COFF/globals.ll
  llvm/test/DebugInfo/COFF/types-array-unsized.ll

Index: llvm/test/DebugInfo/COFF/types-array-unsized.ll
===
--- llvm/test/DebugInfo/COFF/types-array-unsized.ll
+++ llvm/test/DebugInfo/COFF/types-array-unsized.ll
@@ -4,7 +4,7 @@
 ; We should emit two array types: one used to describe the static data member,
 ; and the other used by the S_GDATA32 for the definition.
 
-; C++ source:
+; // Build with: clang-cl a.cpp /c /Z7 /clang:-S /clang:-emit-llvm
 ; struct Foo {
 ;   static const char str[];
 ; };
@@ -12,13 +12,6 @@
 ; Foo f; // FIXME: only needed to force emit 'Foo'
 
 ; CHECK:  CodeViewTypes [
-; CHECK:Array ([[ARRAY_COMPLETE:0x.*]]) {
-; CHECK-NEXT: TypeLeafKind: LF_ARRAY (0x1503)
-; CHECK-NEXT: ElementType: const char ({{.*}})
-; CHECK-NEXT: IndexType: unsigned __int64 (0x23)
-; CHECK-NEXT: SizeOf: 5
-; CHECK-NEXT: Name: 
-; CHECK-NEXT:   }
 ; CHECK:Array ([[ARRAY_FWD:0x.*]]) {
 ; CHECK-NEXT: TypeLeafKind: LF_ARRAY (0x1503)
 ; CHECK-NEXT: ElementType: const char ({{.*}})
@@ -26,7 +19,7 @@
 ; CHECK-NEXT: SizeOf: 0
 ; CHECK-NEXT: Name: 
 ; CHECK-NEXT:   }
-; CHECK:FieldList (0x1004) {
+; CHECK:FieldList (0x1003) {
 ; CHECK-NEXT: TypeLeafKind: LF_FIELDLIST (0x1203)
 ; CHECK-NEXT: StaticDataMember {
 ; CHECK-NEXT:   TypeLeafKind: LF_STMEMBER (0x150E)
@@ -35,39 +28,47 @@
 ; CHECK-NEXT:   Name: str
 ; CHECK-NEXT: }
 ; CHECK-NEXT:   }
+; CHECK:Array ([[ARRAY_COMPLETE:0x.*]]) {
+; CHECK-NEXT: TypeLeafKind: LF_ARRAY (0x1503)
+; CHECK-NEXT: ElementType: const char ({{.*}})
+; CHECK-NEXT: IndexType: unsigned __int64 (0x23)
+; CHECK-NEXT: SizeOf: 5
+; CHECK-NEXT: Name: 
+; CHECK-NEXT:   }
 ; CHECK:  ]
 
 ; CHECK:  GlobalData {
 ; CHECK-NEXT:   Kind: S_GDATA32 (0x110D)
 ; CHECK-NEXT:   DataOffset: ?str@Foo@@2QBDB+0x0
 ; CHECK-NEXT:   Type: [[ARRAY_COMPLETE]]
-; CHECK-NEXT:   DisplayName: str
+; CHECK-NEXT:   DisplayName: Foo::str
 ; CHECK-NEXT:   LinkageName: ?str@Foo@@2QBDB
 ; CHECK-NEXT: }
 
-; ModuleID = 't.cpp'
-source_filename = "t.cpp"
-target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
-target triple = "x86_64-pc-windows-msvc19.0.24215"
+; ModuleID = 'a.cpp'
+source_filename = "a.cpp"
+target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-pc-windows-msvc19.25.28614"
 
 %struct.Foo = type { i8 }
 
-@"\01?str@Foo@@2QBDB" = constant [5 x i8] c"asdf\00", align 1, !dbg !0
-@"\01?f@@3UFoo@@A" = global %struct.Foo zeroinitializer, align 1, !dbg !6
+@"?str@Foo@@2QBDB" = dso_local constant [5 x i8] c"asdf\00", align 1, !dbg !0
+@"?f@@3UFoo@@A" = dso_local global %struct.Foo zeroinitializer, align 1, !dbg !6
 
 !llvm.dbg.cu = !{!2}
-!llvm.module.flags = !{!19, !20, !21, !22}
-!llvm.ident = !{!23}
+!llvm.linker.options = !{!19, !20}
+!llvm.module.flags = !{!21, !22, !23, !24}
+!llvm.ident = !{!25}
 
 !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
-!1 = distinct !DIGlobalVariable(name: "str", linkageName: "\01?str@Foo@@2QBDB", scope: !2, file: !3, line: 4, type: !16, isLocal: false, isDefinition: true, declaration: !10)
-!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "clang version 6.0.0 ", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5)
-!3 = !DIFile(filename: "t.cpp", directory: "C:\5Csrc\5Cllvm-project\5Cbuild", checksumkind: CSK_MD5, checksum: "15aa843c5a80301928caf03e71f87a54")
+!1 = distinct !DIGlobalVariable(name: "str", linkageName: "?str@Foo@@2QBDB", scope: !2, file: !3, line: 4, type: !16, isLocal: false, isDefinition: true, declaration: !10)
+!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !3, producer: "clang version 11.0.0 (https://github.com/llvm/llvm-project.git 202f144bffd0be254a829924195e1b8ebabcbb79)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, nameTableKind: None)
+!3 = !DIFile(filename: "a.cpp", directory: "F:\\llvm-project\\__test", 

[Lldb-commits] [PATCH] D79789: [lldb] Don't dissasemble large functions by default

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: JDevlieghere, jasonmolenda.
Herald added a project: LLDB.

If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.

This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, or start/stop addresses for disassembly.

The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79789

Files:
  lldb/source/Commands/CommandObjectDisassemble.cpp
  lldb/source/Commands/CommandObjectDisassemble.h
  lldb/source/Commands/Options.td
  lldb/test/Shell/Commands/Inputs/command-disassemble.lldbinit
  lldb/test/Shell/Commands/command-disassemble-process.yaml
  lldb/test/Shell/Commands/command-disassemble.s

Index: lldb/test/Shell/Commands/command-disassemble.s
===
--- lldb/test/Shell/Commands/command-disassemble.s
+++ lldb/test/Shell/Commands/command-disassemble.s
@@ -51,8 +51,15 @@
 # CHECK-NEXT: command-disassemble.s.tmp[0x8] <+8>:  int$0x14
 # CHECK-NEXT: command-disassemble.s.tmp[0xa] <+10>: int$0x15
 # CHECK-NEXT: command-disassemble.s.tmp[0xc] <+12>: int$0x16
-# CHECK-NEXT: (lldb) disassemble --address 0xdead
-# CHECK-NEXT: error: Could not find function bounds for address 0xdead
+# CHECK-NEXT: (lldb) disassemble --address 0xdeadb
+# CHECK-NEXT: error: Could not find function bounds for address 0xdeadb
+# CHECK-NEXT: (lldb) disassemble --address 0x100
+# CHECK-NEXT: error: Not disassembling the function because it is very large [0x0040-0x2040). To disassemble, specify an instruction count limit, or start/stop addresses.
+# CHECK-NEXT: (lldb) disassemble --address 0x100 --count 3
+# CHECK-NEXT: command-disassemble.s.tmp`very_long:
+# CHECK-NEXT: command-disassemble.s.tmp[0x40] <+0>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x42] <+2>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x44] <+4>: int$0x2a
 # CHECK-NEXT: (lldb) disassemble --start-address 0x0 --count 7
 # CHECK-NEXT: command-disassemble.s.tmp`foo:
 # CHECK-NEXT: command-disassemble.s.tmp[0x0] <+0>:  int$0x10
@@ -64,8 +71,32 @@
 # CHECK-NEXT: command-disassemble.s.tmp[0xc] <+12>: int$0x16
 # CHECK-NEXT: (lldb) disassemble --start-address 0x0 --end-address 0x20 --count 7
 # CHECK-NEXT: error: invalid combination of options for the given command
-# CHECK-NEXT: (lldb) disassemble --address 0x0 --count 7
-# CHECK-NEXT: error: invalid combination of options for the given command
+# CHECK-NEXT: (lldb) disassemble --name case1
+# CHECK-NEXT: command-disassemble.s.tmp`n1::case1:
+# CHECK-NEXT: command-disassemble.s.tmp[0x2040] <+0>: int$0x30
+# CHECK-EMPTY:
+# CHECK-NEXT: command-disassemble.s.tmp`n2::case1:
+# CHECK-NEXT: command-disassemble.s.tmp[0x2042] <+0>: int$0x31
+# CHECK-EMPTY:
+# CHECK-NEXT: (lldb) disassemble --name case2
+# CHECK-NEXT: command-disassemble.s.tmp`n1::case2:
+# CHECK-NEXT: command-disassemble.s.tmp[0x2044] <+0>: int$0x32
+# CHECK-NEXT: warning: Not disassembling a range because it is very large [0x2046-0x4046). To disassemble, specify an instruction count limit, or start/stop addresses.
+# CHECK-NEXT: (lldb) disassemble --name case3
+# CHECK-NEXT: error: Not disassembling a range because it is very large [0x4046-0x6046). To disassemble, specify an instruction count limit, or start/stop addresses.
+# CHECK-NEXT: Not disassembling a range because it is very large [0x6046-0x8046). To disassemble, specify an instruction count limit, or start/stop addresses.
+# CHECK-NEXT: (lldb) disassemble --name case3 --count 3
+# CHECK-NEXT: command-disassemble.s.tmp`n1::case3:
+# CHECK-NEXT: command-disassemble.s.tmp[0x4046] <+0>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x4048] <+2>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x404a] <+4>: int$0x2a
+# CHECK-EMPTY:
+# CHECK-NEXT: command-disassemble.s.tmp`n2::case3:
+# CHECK-NEXT: command-disassemble.s.tmp[0x6046] <+0>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x6048] <+2>: int$0x2a
+# CHECK-NEXT: command-disassemble.s.tmp[0x604a] <+4>: int$0x2a
+# CHECK-EMPTY:
+
 
 .text
 foo:
@@ -102,3 +133,32 @@
 int $0x2d
 int 

[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Mathias LANG via Phabricator via lldb-commits
Geod24 updated this revision to Diff 263442.
Geod24 added a comment.

Remove un-needed main & use x86_64-pc-gnu as target instead of host

Since we're not running the program anymore, we no longer need a main.
The comment, build step, and IR of the test were updated accordingly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll

Index: lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
@@ -0,0 +1,73 @@
+;
+; This test verifies that DWARF DIE of type DW_TAG_basic_type with DW_ATE_UTF
+; are matched based on their bit size (8, 16, 32) in addition to their name.
+;
+; This is used by languages which don't use the C(++) naming of
+; `char{8,16,32}_t`, e.g. the D programming language uses `char`, `wchar`, `dchar`.
+;
+; The D code used to generate this IR is:
+; ```
+; // Compiled with `ldc2 --mtriple=x86_64-pc-linux -betterC -g -c --output-ll utftypes.d`
+; __gshared string utf8 = "Hello";
+; __gshared wstring utf16 = "Dlang"w;
+; __gshared dstring utf32 = "World"d;
+; ```
+;
+; Note: lldb will print types differently before and after 'run'.
+;
+; RUN: %clang --target=x86_64-pc-linu -c -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s
+;
+; CHECK: struct string {
+; CHECK: unsigned long length;
+; CHECK: char8_t *ptr;
+; CHECK: }
+
+$_D8utftypes4utf8Aya = comdat any
+$_D8utftypes5utf16Ayu = comdat any
+$_D8utftypes5utf32Ayw = comdat any
+
+@_D8utftypes4utf8Aya = global { i64, i8* } { i64 5, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str, i32 0, i32 0) }, comdat, align 8, !dbg !0 ; [#uses = 0]
+@.str = private unnamed_addr constant [6 x i8] c"Hello\00" ; [#uses = 1]
+@_D8utftypes5utf16Ayu = global { i64, i16* } { i64 5, i16* getelementptr inbounds ([6 x i16], [6 x i16]* @.str.1, i32 0, i32 0) }, comdat, align 8, !dbg !11 ; [#uses = 0]
+@.str.1 = private unnamed_addr constant [6 x i16] [i16 68, i16 108, i16 97, i16 110, i16 103, i16 0] ; [#uses = 1]
+@_D8utftypes5utf32Ayw = global { i64, i32* } { i64 5, i32* getelementptr inbounds ([6 x i32], [6 x i32]* @.str.2, i32 0, i32 0) }, comdat, align 8, !dbg !18 ; [#uses = 0]
+@.str.2 = private unnamed_addr constant [6 x i32] [i32 87, i32 111, i32 114, i32 108, i32 100, i32 0] ; [#uses = 1]
+
+!llvm.module.flags = !{!25}
+!llvm.dbg.cu = !{!26}
+!llvm.ident = !{!32}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "utf8", linkageName: "_D8utftypes4utf8Aya", scope: !2, file: !3, line: 1, type: !4, isLocal: false, isDefinition: true)
+!2 = !DIModule(scope: null, name: "utftypes")
+!3 = !DIFile(filename: "utftypes.d", directory: "/tmp")
+!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "string", file: !3, size: 128, align: 64, elements: !5, identifier: "Aya")
+!5 = !{!6, !8}
+!6 = !DIDerivedType(tag: DW_TAG_member, name: "length", file: !3, baseType: !7, size: 64, align: 64, flags: DIFlagPublic)
+!7 = !DIBasicType(name: "ulong", size: 64, encoding: DW_ATE_unsigned)
+!8 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !9, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(char)*", baseType: !10, size: 64, align: 64)
+!10 = !DIBasicType(name: "immutable(char)", size: 8, encoding: DW_ATE_UTF)
+!11 = !DIGlobalVariableExpression(var: !12, expr: !DIExpression())
+!12 = distinct !DIGlobalVariable(name: "utf16", linkageName: "_D8utftypes5utf16Ayu", scope: !2, file: !3, line: 2, type: !13, isLocal: false, isDefinition: true)
+!13 = !DICompositeType(tag: DW_TAG_structure_type, name: "wstring", file: !3, size: 128, align: 64, elements: !14, identifier: "Ayu")
+!14 = !{!6, !15}
+!15 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !16, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(wchar)*", baseType: !17, size: 64, align: 64)
+!17 = !DIBasicType(name: "immutable(wchar)", size: 16, encoding: DW_ATE_UTF)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = distinct !DIGlobalVariable(name: "utf32", linkageName: "_D8utftypes5utf32Ayw", scope: !2, file: !3, line: 3, type: !20, isLocal: false, isDefinition: true)
+!20 = !DICompositeType(tag: DW_TAG_structure_type, name: "dstring", file: !3, size: 128, align: 64, elements: !21, identifier: "Ayw")
+!21 = !{!6, !22}
+!22 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !23, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!23 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(dchar)*", baseType: !24, size: 

[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks great now, just a small tweak to the test case.




Comment at: 
lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll:19
+;
+; RUN: %clang_host -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s

Now that we're not running the binary, you can remove the `main` function, and 
replace `%clang_host` with `%clang --target original-ldc2-target -c`. Without 
that, we might as well have run the binary, because if it compiles for the 
host, chances are it would have run correctly too...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559



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


[Lldb-commits] [PATCH] D79623: [LLDB] Add Linux SVE Ptrace macros.

2020-05-12 Thread Kristof Beyls via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5d7f5ca0e385: Add Linux SVE Ptrace macros. (authored by 
kristof.beyls).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79623

Files:
  lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h

Index: lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h
@@ -0,0 +1,253 @@
+//===-- LinuxPTraceDefines_arm64sve.h - -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_LinuxPTraceDefines_arm64sve_h
+#define lldb_LinuxPTraceDefines_arm64sve_h
+
+#define SVE_MAGIC 0x53564501
+
+struct sve_context {
+  struct _aarch64_ctx head;
+  __u16 vl;
+  __u16 __reserved[3];
+};
+
+/*
+ * The SVE architecture leaves space for future expansion of the
+ * vector length beyond its initial architectural limit of 2048 bits
+ * (16 quadwords).
+ *
+ * See linux/Documentation/arm64/sve.txt for a description of the VL/VQ
+ * terminology.
+ */
+#define SVE_VQ_BYTES 16 /* number of bytes per quadword */
+
+#define SVE_VQ_MIN 1
+#define SVE_VQ_MAX 512
+
+#define SVE_VL_MIN (SVE_VQ_MIN * SVE_VQ_BYTES)
+#define SVE_VL_MAX (SVE_VQ_MAX * SVE_VQ_BYTES)
+
+#define SVE_NUM_ZREGS 32
+#define SVE_NUM_PREGS 16
+
+#define sve_vl_valid(vl)   \
+  ((vl) % SVE_VQ_BYTES == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX)
+#define sve_vq_from_vl(vl) ((vl) / SVE_VQ_BYTES)
+#define sve_vl_from_vq(vq) ((vq)*SVE_VQ_BYTES)
+
+/*
+ * If the SVE registers are currently live for the thread at signal delivery,
+ * sve_context.head.size >=
+ *	SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl))
+ * and the register data may be accessed using the SVE_SIG_*() macros.
+ *
+ * If sve_context.head.size <
+ *	SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)),
+ * the SVE registers were not live for the thread and no register data
+ * is included: in this case, the SVE_SIG_*() macros should not be
+ * used except for this check.
+ *
+ * The same convention applies when returning from a signal: a caller
+ * will need to remove or resize the sve_context block if it wants to
+ * make the SVE registers live when they were previously non-live or
+ * vice-versa.  This may require the the caller to allocate fresh
+ * memory and/or move other context blocks in the signal frame.
+ *
+ * Changing the vector length during signal return is not permitted:
+ * sve_context.vl must equal the thread's current vector length when
+ * doing a sigreturn.
+ *
+ *
+ * Note: for all these macros, the "vq" argument denotes the SVE
+ * vector length in quadwords (i.e., units of 128 bits).
+ *
+ * The correct way to obtain vq is to use sve_vq_from_vl(vl).  The
+ * result is valid if and only if sve_vl_valid(vl) is true.  This is
+ * guaranteed for a struct sve_context written by the kernel.
+ *
+ *
+ * Additional macros describe the contents and layout of the payload.
+ * For each, SVE_SIG_x_OFFSET(args) is the start offset relative to
+ * the start of struct sve_context, and SVE_SIG_x_SIZE(args) is the
+ * size in bytes:
+ *
+ *	x	typedescription
+ *	-	---
+ *	REGS	the entire SVE context
+ *
+ *	ZREGS	__uint128_t[SVE_NUM_ZREGS][vq]	all Z-registers
+ *	ZREG	__uint128_t[vq]			individual Z-register Zn
+ *
+ *	PREGS	uint16_t[SVE_NUM_PREGS][vq]	all P-registers
+ *	PREG	uint16_t[vq]			individual P-register Pn
+ *
+ *	FFR	uint16_t[vq]			first-fault status register
+ *
+ * Additional data might be appended in the future.
+ */
+
+#define SVE_SIG_ZREG_SIZE(vq) ((__u32)(vq)*SVE_VQ_BYTES)
+#define SVE_SIG_PREG_SIZE(vq) ((__u32)(vq) * (SVE_VQ_BYTES / 8))
+#define SVE_SIG_FFR_SIZE(vq) SVE_SIG_PREG_SIZE(vq)
+
+#define SVE_SIG_REGS_OFFSET\
+  ((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1)) / SVE_VQ_BYTES *  \
+   SVE_VQ_BYTES)
+
+#define SVE_SIG_ZREGS_OFFSET SVE_SIG_REGS_OFFSET
+#define SVE_SIG_ZREG_OFFSET(vq, n) \
+  (SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREG_SIZE(vq) * (n))
+#define SVE_SIG_ZREGS_SIZE(vq) \
+  (SVE_SIG_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_SIG_ZREGS_OFFSET)
+
+#define SVE_SIG_PREGS_OFFSET(vq) (SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREGS_SIZE(vq))
+#define SVE_SIG_PREG_OFFSET(vq, n) \
+  (SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREG_SIZE(vq) * (n))
+#define SVE_SIG_PREGS_SIZE(vq) 

[Lldb-commits] [PATCH] D77043: Fix process gdb-remote usage of value_regs/invalidate_regs

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

The invalidate_regs part looks as I would expect. I think it ought to be 
implemented a bit differently, but that can wait until the bigger issue is 
resolved.

The bigger issue being the fact that this patch now renumbers all numbers going 
in/out of the stub (qRegisterInfo, p,P, etc.). It seems I got more than what I 
bargained for there, though in retrospect, that does not seem totally 
unexpected, as you were mentioning the problem of the extra dbg registers in 
the middle of the register list. The part which I didn't get is that this does 
not only apply to the "lldb" register list, but that these registers also make 
their way to `NativeRegisterContextLinux_arm64::GetRegisterInfoAtIndex`. 
Currently that class was culling them (in the same way as other register 
contexts do for "optional" registers) by returning a smaller value via 
GetUserRegisterCount. That is, of course, not possible if you have other 
registers in the list that you want to make available.

So, IIUC, what the current patch does is expose the registers through 
GetRegisterInfoAtIndex, but then ensures that the `UserRegIndexToRegInfosIndex` 
conversion skips over them. That wouldn't be too bad were it not for the fact 
that accessing the register "the right way" is very hard now.

So here's my current doubt. Basically, the main thing this patch does is "hide" 
the uninteresting (debug) registers from the client. However, those registers 
still remain exposed through the 
NativeRegisterContext<->GDBRemoteCommunicationServerLLGS boundary via the 
`GetRegisterInfoAtIndex` function. What if we took this one step further, and 
made is so that the debug registers are not exposed from 
NativeRegisterContextLinux_arm64 at all?

One way to achieve that would be to handle the renumbering inside 
`GetRegisterInfoAtIndex`. Another would be to ensure that these registers don't 
even appear in the RegisterInfo array that backs this function (then the 
current implementation of `GetRegisterInfoAtIndex` would "just work"). All 
other things being equal, I would prefer the second approach. It seems like 
that could be easily achieved as you're defining a custom RegisterInfo array 
for SVE anyway (`g_register_infos_arm64_sve_le` in D77047 
). We could just exclude dbg registers from 
that list.

That would still leave us with the question of what does `invalidate_regs` 
refer to. If it still makes sense for it to refer to "lldb" register numbers, 
then we can remap it as we discussed previously. But it may turn out that after 
no remapping is needed -- in which case, even better.


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

https://reviews.llvm.org/D77043



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


[Lldb-commits] [lldb] 5d7f5ca - Add Linux SVE Ptrace macros.

2020-05-12 Thread Kristof Beyls via lldb-commits

Author: Kristof Beyls
Date: 2020-05-12T15:24:24+02:00
New Revision: 5d7f5ca0e385ebc05231997a66cdd5f18b9d2f72

URL: 
https://github.com/llvm/llvm-project/commit/5d7f5ca0e385ebc05231997a66cdd5f18b9d2f72
DIFF: 
https://github.com/llvm/llvm-project/commit/5d7f5ca0e385ebc05231997a66cdd5f18b9d2f72.diff

LOG: Add Linux SVE Ptrace macros.

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

Added: 
lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h

Modified: 


Removed: 




diff  --git a/lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h 
b/lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h
new file mode 100644
index ..18ba39d55b1b
--- /dev/null
+++ b/lldb/source/Plugins/Process/Linux/LinuxPTraceDefines_arm64sve.h
@@ -0,0 +1,253 @@
+//===-- LinuxPTraceDefines_arm64sve.h - -*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_LinuxPTraceDefines_arm64sve_h
+#define lldb_LinuxPTraceDefines_arm64sve_h
+
+#define SVE_MAGIC 0x53564501
+
+struct sve_context {
+  struct _aarch64_ctx head;
+  __u16 vl;
+  __u16 __reserved[3];
+};
+
+/*
+ * The SVE architecture leaves space for future expansion of the
+ * vector length beyond its initial architectural limit of 2048 bits
+ * (16 quadwords).
+ *
+ * See linux/Documentation/arm64/sve.txt for a description of the VL/VQ
+ * terminology.
+ */
+#define SVE_VQ_BYTES 16 /* number of bytes per quadword */
+
+#define SVE_VQ_MIN 1
+#define SVE_VQ_MAX 512
+
+#define SVE_VL_MIN (SVE_VQ_MIN * SVE_VQ_BYTES)
+#define SVE_VL_MAX (SVE_VQ_MAX * SVE_VQ_BYTES)
+
+#define SVE_NUM_ZREGS 32
+#define SVE_NUM_PREGS 16
+
+#define sve_vl_valid(vl)   
\
+  ((vl) % SVE_VQ_BYTES == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX)
+#define sve_vq_from_vl(vl) ((vl) / SVE_VQ_BYTES)
+#define sve_vl_from_vq(vq) ((vq)*SVE_VQ_BYTES)
+
+/*
+ * If the SVE registers are currently live for the thread at signal delivery,
+ * sve_context.head.size >=
+ * SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl))
+ * and the register data may be accessed using the SVE_SIG_*() macros.
+ *
+ * If sve_context.head.size <
+ * SVE_SIG_CONTEXT_SIZE(sve_vq_from_vl(sve_context.vl)),
+ * the SVE registers were not live for the thread and no register data
+ * is included: in this case, the SVE_SIG_*() macros should not be
+ * used except for this check.
+ *
+ * The same convention applies when returning from a signal: a caller
+ * will need to remove or resize the sve_context block if it wants to
+ * make the SVE registers live when they were previously non-live or
+ * vice-versa.  This may require the the caller to allocate fresh
+ * memory and/or move other context blocks in the signal frame.
+ *
+ * Changing the vector length during signal return is not permitted:
+ * sve_context.vl must equal the thread's current vector length when
+ * doing a sigreturn.
+ *
+ *
+ * Note: for all these macros, the "vq" argument denotes the SVE
+ * vector length in quadwords (i.e., units of 128 bits).
+ *
+ * The correct way to obtain vq is to use sve_vq_from_vl(vl).  The
+ * result is valid if and only if sve_vl_valid(vl) is true.  This is
+ * guaranteed for a struct sve_context written by the kernel.
+ *
+ *
+ * Additional macros describe the contents and layout of the payload.
+ * For each, SVE_SIG_x_OFFSET(args) is the start offset relative to
+ * the start of struct sve_context, and SVE_SIG_x_SIZE(args) is the
+ * size in bytes:
+ *
+ * x   typedescription
+ * -   ---
+ * REGSthe entire SVE context
+ *
+ * ZREGS   __uint128_t[SVE_NUM_ZREGS][vq]  all Z-registers
+ * ZREG__uint128_t[vq] individual Z-register Zn
+ *
+ * PREGS   uint16_t[SVE_NUM_PREGS][vq] all P-registers
+ * PREGuint16_t[vq]individual P-register Pn
+ *
+ * FFR uint16_t[vq]first-fault status register
+ *
+ * Additional data might be appended in the future.
+ */
+
+#define SVE_SIG_ZREG_SIZE(vq) ((__u32)(vq)*SVE_VQ_BYTES)
+#define SVE_SIG_PREG_SIZE(vq) ((__u32)(vq) * (SVE_VQ_BYTES / 8))
+#define SVE_SIG_FFR_SIZE(vq) SVE_SIG_PREG_SIZE(vq)
+
+#define SVE_SIG_REGS_OFFSET
\
+  ((sizeof(struct sve_context) + (SVE_VQ_BYTES - 1)) / SVE_VQ_BYTES *  
\
+   SVE_VQ_BYTES)
+
+#define SVE_SIG_ZREGS_OFFSET SVE_SIG_REGS_OFFSET
+#define SVE_SIG_ZREG_OFFSET(vq, n) 
\
+  

[Lldb-commits] [PATCH] D79777: Fix error in TestNumThreads.py when frame.GetFunctionName returns none

2020-05-12 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid created this revision.
omjavaid added a reviewer: labath.
Herald added a subscriber: kristof.beyls.

This patch fixes an error happening in TestNumThreads.py when it encounters 
frame.GetFunctionName none for address only locations in stripped libc.

This error was showing up on arm-linux docker container running lldb buildbot.


https://reviews.llvm.org/D79777

Files:
  lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py


Index: lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
===
--- lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
+++ lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
@@ -95,6 +95,8 @@
 # the same breakpoint.
 def is_thread3(thread):
 for frame in thread:
+if frame.GetFunctionName() is None:
+continue
 if "thread3" in frame.GetFunctionName(): return True
 return False
 


Index: lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
===
--- lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
+++ lldb/test/API/functionalities/thread/num_threads/TestNumThreads.py
@@ -95,6 +95,8 @@
 # the same breakpoint.
 def is_thread3(thread):
 for frame in thread:
+if frame.GetFunctionName() is None:
+continue
 if "thread3" in frame.GetFunctionName(): return True
 return False
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D79559: [lldb] Also recognize DWARF UTF base types using their size

2020-05-12 Thread Mathias LANG via Phabricator via lldb-commits
Geod24 updated this revision to Diff 263401.
Geod24 added a comment.

Changed the test from running to 'type lookup string'

Due to bug https://bugs.llvm.org/show_bug.cgi?id=45856 the test was originally 
runnable,
but a non-runnable alternative was suggested during review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll

Index: lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/DW_TAG_basic_type_DW_ATE_UTF_nonC.ll
@@ -0,0 +1,84 @@
+;
+; This test verifies that DWARF DIE of type DW_TAG_basic_type with DW_ATE_UTF
+; are matched based on their bit size (8, 16, 32) in addition to their name.
+;
+; This is used by languages which don't use the C(++) naming of
+; `char{8,16,32}_t`, e.g. the D programming language uses `char`, `wchar`, `dchar`.
+;
+; The D code used to generate this IR is:
+; ```
+; // Compiled with `ldc2 -betterC -g --output-ll utftypes.d`
+; __gshared string utf8 = "Hello";
+; __gshared wstring utf16 = "Dlang"w;
+; __gshared dstring utf32 = "World"d;
+; extern(C) int main () { return 0; }
+; ```
+;
+; Note: lldb will print types differently before and after 'run'.
+;
+; RUN: %clang_host -g -o %t %s
+; RUN: %lldb %t -o 'type lookup string' -o exit | FileCheck %s
+;
+; CHECK: struct string {
+; CHECK: unsigned long length;
+; CHECK: char8_t *ptr;
+; CHECK: }
+
+
+@_D8utftypes4utf8Aya = global { i64, i8* } { i64 5, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @.str, i32 0, i32 0) }, align 8, !dbg !0 ; [#uses = 0]
+@.str = private unnamed_addr constant [6 x i8] c"Hello\00" ; [#uses = 1]
+@_D8utftypes5utf16Ayu = global { i64, i16* } { i64 5, i16* getelementptr inbounds ([6 x i16], [6 x i16]* @.str.1, i32 0, i32 0) }, align 8, !dbg !11 ; [#uses = 0]
+@.str.1 = private unnamed_addr constant [6 x i16] [i16 68, i16 108, i16 97, i16 110, i16 103, i16 0] ; [#uses = 1]
+@_D8utftypes5utf32Ayw = global { i64, i32* } { i64 5, i32* getelementptr inbounds ([6 x i32], [6 x i32]* @.str.2, i32 0, i32 0) }, align 8, !dbg !18 ; [#uses = 0]
+@.str.2 = private unnamed_addr constant [6 x i32] [i32 87, i32 111, i32 114, i32 108, i32 100, i32 0] ; [#uses = 1]
+
+; [#uses = 0] [display name = main]
+; Function Attrs: uwtable
+define i32 @main() #0 !dbg !33 {
+  ret i32 0, !dbg !37 ; [debug line = utftypes.d:7:25]
+}
+
+attributes #0 = { uwtable "frame-pointer"="all" "less-precise-fpmad"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "target-cpu"="core2" "unsafe-fp-math"="false" }
+
+!llvm.module.flags = !{!25}
+!llvm.dbg.cu = !{!26}
+!llvm.ident = !{!32}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "utf8", linkageName: "_D8utftypes4utf8Aya", scope: !2, file: !3, line: 4, type: !4, isLocal: false, isDefinition: true)
+!2 = !DIModule(scope: null, name: "utftypes")
+!3 = !DIFile(filename: "utftypes.d", directory: "/tmp")
+!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "string", file: !3, size: 128, align: 64, elements: !5, identifier: "Aya")
+!5 = !{!6, !8}
+!6 = !DIDerivedType(tag: DW_TAG_member, name: "length", file: !3, baseType: !7, size: 64, align: 64, flags: DIFlagPublic)
+!7 = !DIBasicType(name: "ulong", size: 64, encoding: DW_ATE_unsigned)
+!8 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !9, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(char)*", baseType: !10, size: 64, align: 64)
+!10 = !DIBasicType(name: "immutable(char)", size: 8, encoding: DW_ATE_UTF)
+!11 = !DIGlobalVariableExpression(var: !12, expr: !DIExpression())
+!12 = distinct !DIGlobalVariable(name: "utf16", linkageName: "_D8utftypes5utf16Ayu", scope: !2, file: !3, line: 5, type: !13, isLocal: false, isDefinition: true)
+!13 = !DICompositeType(tag: DW_TAG_structure_type, name: "wstring", file: !3, size: 128, align: 64, elements: !14, identifier: "Ayu")
+!14 = !{!6, !15}
+!15 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", file: !3, baseType: !16, size: 64, align: 64, offset: 64, flags: DIFlagPublic)
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "immutable(wchar)*", baseType: !17, size: 64, align: 64)
+!17 = !DIBasicType(name: "immutable(wchar)", size: 16, encoding: DW_ATE_UTF)
+!18 = !DIGlobalVariableExpression(var: !19, expr: !DIExpression())
+!19 = distinct !DIGlobalVariable(name: "utf32", linkageName: "_D8utftypes5utf32Ayw", scope: !2, file: !3, line: 6, type: !20, isLocal: false, isDefinition: true)
+!20 = !DICompositeType(tag: DW_TAG_structure_type, name: "dstring", file: !3, size: 128, align: 64, elements: !21, identifier: "Ayw")
+!21 = !{!6, !22}
+!22 = 

[Lldb-commits] [PATCH] D77047: AArch64 SVE register infos and core file support

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

(sorry about all the editing -- I'm trying to figure out the order of these 
patches)


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

https://reviews.llvm.org/D77047



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


[Lldb-commits] [PATCH] D79757: Try IPv4 before IPv6 when creating TCP connection

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Getaddrinfo documentation says:

  Normally,  the  application
  should  try  using the addresses in the order in which they are returned.  
The sorting function
  used within getaddrinfo() is defined in RFC 3484; the order can be  tweaked  
for  a  particular
  system by editing /etc/gai.conf (available since glibc 2.5).

I don't like when apps question or try to override system settings. And 
preferring ipv4 seems rather backward-looking.

So, IIUC, the problem is that adb only listens on the ipv4 loopback address 
(and that windows takes 2 seconds to reject a loopback connection). Is that 
correct? Where do the addresses that we're connecting to come from (the user or 
lldb code)? If it's lldb code, maybe we could just replace the relevant 
"localhost" names with an explicit ipv4 loopback address?

Also, have you looked at the possibility of reducing the number of adb 
connections we make? My memory of adb is fairly hazy, but I do remember that 
some queries result in immediate connection termination. Still, five 
connections seems like too much...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79757



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


[Lldb-commits] [PATCH] D79654: [lldb/Driver] Support terminal resizing

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Yes, you're right that the current implementation of Editline::Interrupt is not 
correct. It's kind of my fault since I added that locking code (in my defense, 
the code was pretty messy to begin with). The implementation could indeed 
deadlock if the signal is delivered on the thread which does the editline 
reading. The reason why this does not happen in practice is probably because 
the signal is indeed not delievered on the editline thread. Posix leaves this 
behavior unspecified, but implementations have to actually make a choice, and I 
believe most do it in such a way that they first try the main thread, and only 
if that has the signal blocked, they try searching for other victims. The 
problem could also be reproduced with an well-timed manual SIGINT, if the os 
supports sending signals to a specific thread (linux does via non-standard 
tgkill(2), I don't know about the rest).

Right now, I don't really remember whether that locking was solving any 
specific problem or if it was a case of "well, this code is touching variables 
that may be accessed concurrently, so I better lock it...". If I had to guess, 
I would say it's the latter. The `fprintf` operation, and messing with 
`m_editor_status` are indeed not safe to perform without additional 
synchronization. But as we've established, a mutex is not a good method of 
synchronization with a signal handler. There are several ways to fix this. The 
fix will probably won't require touching a lot of code, but it will need to be 
done with a steady hand. It will likely involve moving things out of the signal 
handler (`fprintf("^C")` could easily be done in the main thread), making 
things std::atomic/std::sig_atomic or blocking signals in some critical 
sections. Most likely a combination of approaches would be needed.

So, anyway, I think it's fine to either keep the current form of the patch, do 
it similarly to how SIGINT is handled (knowing that it's not fully posix 
compliant, and hoping that someone will eventually make both things compliant), 
or try to make everything posix compliant right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79654



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


[Lldb-commits] [PATCH] D79726: Add terminateCommands to lldb-vscode protocol

2020-05-12 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I gotta say I don't understand the difference between "exit" and "terminate" 
commands, as both seem to happen pretty at once. Is the difference that "exit" 
commands are run only when the inferior exits freely on its own, and not when 
we forcefully kill it? And that "terminate" cmds are run in both cases?

If you say that they are useful, then sure, I don't see a reason to not do 
this, though it seems to me like this will be confusing, and would be worth 
documenting somewhere. Maybe in that json file (I forgot where it's stored) 
which defines the protocol extensions used by lldb-vscode?




Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py:250-251
 def cleanup():
-self.vscode.request_disconnect(terminateDebuggee=True)
+if disconnect:
+self.vscode.request_disconnect(terminateDebuggee=True)
 self.vscode.terminate()

What's the purpose of this argument? To ensure a clean shutdown? Would it be 
possible to make the function smart enough to detect the right thing to do when 
cleaning up?



Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:777
   auto state = process.GetState();
-
+  g_vsc.RunTerminateCommands();
   switch (state) {

How about moving this to line ~801 so that it is sent *after* the inferior is 
killed, similar to how you above perform the commands after receiving the exit 
event?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79726



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


[Lldb-commits] [PATCH] D79491: [lldb] Revive TestBasicEntryValuesX86_64

2020-05-12 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

This breaks on arm-linux. I am going remove arm temporarily.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79491



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


[Lldb-commits] [lldb] 054ed1f - [LLDB] Disable TestBasicEntryValues.py for arm

2020-05-12 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-05-12T11:32:58+05:00
New Revision: 054ed1fd0b8dfbd996299f11dfe2311f428297da

URL: 
https://github.com/llvm/llvm-project/commit/054ed1fd0b8dfbd996299f11dfe2311f428297da
DIFF: 
https://github.com/llvm/llvm-project/commit/054ed1fd0b8dfbd996299f11dfe2311f428297da.diff

LOG: [LLDB] Disable TestBasicEntryValues.py for arm

TestBasicEntryValues.py fails on arm 32 bit. Currently running on silent master 
here:
http://lab.llvm.org:8014/builders/lldb-arm-ubuntu/

Added: 


Modified: 

lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py
 
b/lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py
index c628a6bd4389..94689d14f990 100644
--- 
a/lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py
+++ 
b/lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py
@@ -2,7 +2,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test import lldbplatformutil
 
-supported_archs = ["x86_64", "arm", "aarch64"]
+supported_archs = ["x86_64", "aarch64"]
 
 lldbinline.MakeInlineTest(__file__, globals(),
 [skipIf(archs=no_match(supported_archs)),



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