[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: labath, krytarowski.
Herald added a subscriber: jfb.
mgorny added a parent revision: D70025: [lldb] [Process/NetBSD] Fix handling 
concurrent watchpoint events.

Add a test that verifies that when the user does not have permissions
to set watchpoints on NetBSD, the 'watchpoint set' errors out gracefully
and thread monitoring does not crash on being unable to copy watchpoints
to new threads.


https://reviews.llvm.org/D70050

Files:
  lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
  lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
  lldb/test/Shell/lit.cfg.py


Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -5,6 +5,7 @@
 import re
 import shutil
 import site
+import subprocess
 import sys
 
 import lit.formats
@@ -103,3 +104,17 @@
 
 if find_executable('xz') != None:
 config.available_features.add('xz')
+
+# NetBSD permits setting dbregs either if one is root
+# or if user_set_dbregs is enabled
+can_set_dbregs = True
+if platform.system() == 'NetBSD' and os.geteuid() != 0:
+try:
+output = subprocess.check_output(["/sbin/sysctl", "-n",
+  "security.models.extensions.user_set_dbregs"]).decode().strip()
+if output != "1":
+can_set_dbregs = False
+except subprocess.CalledProcessError:
+can_set_dbregs = False
+if can_set_dbregs:
+config.available_features.add('dbregs-set')
Index: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
===
--- /dev/null
+++ lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
@@ -0,0 +1,22 @@
+# Check that 'watchpoint set' errors out gracefully when we can't set dbregs
+# and that new threads are monitored correctly even though we can't copy 
dbregs.
+
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && 
!dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %s %t.out 2>&1 | FileCheck %s
+
+settings show interpreter.stop-command-source-on-error
+# CHECK: interpreter.stop-command-source-on-error (boolean) = false
+
+b main
+# CHECK: Breakpoint {{[0-9]+}}: where = {{.*}}`main
+b thread_func
+# CHECK: Breakpoint {{[0-9]+}}: where = {{.*}}`thread_func
+run
+# CHECK: stop reason = breakpoint
+watchpoint set variable g_watchme
+# CHECK: error: Watchpoint creation failed
+cont
+# CHECK: stop reason = breakpoint
+cont
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
===
--- /dev/null
+++ lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
@@ -0,0 +1,23 @@
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;
+  return 0;
+}
+
+int main() {
+  pthread_t thread;
+  if (pthread_create(&thread, 0, thread_func, 0))
+return 1;
+
+  /* watchpoint trigger from main thread */
+  g_watchme = 1;
+
+  if (pthread_join(thread, 0))
+return 2;
+
+  return 0;
+}


Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -5,6 +5,7 @@
 import re
 import shutil
 import site
+import subprocess
 import sys
 
 import lit.formats
@@ -103,3 +104,17 @@
 
 if find_executable('xz') != None:
 config.available_features.add('xz')
+
+# NetBSD permits setting dbregs either if one is root
+# or if user_set_dbregs is enabled
+can_set_dbregs = True
+if platform.system() == 'NetBSD' and os.geteuid() != 0:
+try:
+output = subprocess.check_output(["/sbin/sysctl", "-n",
+  "security.models.extensions.user_set_dbregs"]).decode().strip()
+if output != "1":
+can_set_dbregs = False
+except subprocess.CalledProcessError:
+can_set_dbregs = False
+if can_set_dbregs:
+config.available_features.add('dbregs-set')
Index: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
===
--- /dev/null
+++ lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
@@ -0,0 +1,22 @@
+# Check that 'watchpoint set' errors out gracefully when we can't set dbregs
+# and that new threads are monitored correctly even though we can't copy dbregs.
+
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && !dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error false' -s %s %t.out 2>&1 | FileCheck %s
+
+settings show interpreter.stop-command-source-on-error
+# CHECK: interpreter.stop-command-source-on-error (boolean) = false
+
+b main
+# CHECK: Breakpoint {{[0-9]+}}: where = {{.*}}`main
+b thread_func
+# CHECK: Break

[Lldb-commits] [PATCH] D63540: Fix lookup of symbols at the same address with no size vs. size

2019-11-11 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

I am going to investigate it this week. Feel free to revert it but some such 
patch is definitely needed for all recent Fedoras, RHEL-8 and CentOS-8 (due to 
annobin 

 on all those).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63540



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


[Lldb-commits] [PATCH] D70060: [lldb] [Process/NetBSD] Use PT_STOP to stop the process

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: labath, krytarowski.

https://reviews.llvm.org/D70060

Files:
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h


Index: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
===
--- lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
+++ lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
@@ -47,6 +47,8 @@
 
   Status Signal(int signo) override;
 
+  Status Interrupt() override;
+
   Status Kill() override;
 
   Status GetMemoryRegionInfo(lldb::addr_t load_addr,
Index: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
@@ -490,12 +490,7 @@
 }
 
 Status NativeProcessNetBSD::Halt() {
-  Status error;
-
-  if (kill(GetID(), SIGSTOP) != 0)
-error.SetErrorToErrno();
-
-  return error;
+  return PtraceWrapper(PT_STOP, GetID());
 }
 
 Status NativeProcessNetBSD::Detach() {
@@ -520,6 +515,10 @@
   return error;
 }
 
+Status NativeProcessNetBSD::Interrupt() {
+  return PtraceWrapper(PT_STOP, GetID());
+}
+
 Status NativeProcessNetBSD::Kill() {
   Log *log(ProcessPOSIXLog::GetLogIfAllCategoriesSet(POSIX_LOG_PROCESS));
   LLDB_LOG(log, "pid {0}", GetID());


Index: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
===
--- lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
+++ lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
@@ -47,6 +47,8 @@
 
   Status Signal(int signo) override;
 
+  Status Interrupt() override;
+
   Status Kill() override;
 
   Status GetMemoryRegionInfo(lldb::addr_t load_addr,
Index: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
@@ -490,12 +490,7 @@
 }
 
 Status NativeProcessNetBSD::Halt() {
-  Status error;
-
-  if (kill(GetID(), SIGSTOP) != 0)
-error.SetErrorToErrno();
-
-  return error;
+  return PtraceWrapper(PT_STOP, GetID());
 }
 
 Status NativeProcessNetBSD::Detach() {
@@ -520,6 +515,10 @@
   return error;
 }
 
+Status NativeProcessNetBSD::Interrupt() {
+  return PtraceWrapper(PT_STOP, GetID());
+}
+
 Status NativeProcessNetBSD::Kill() {
   Log *log(ProcessPOSIXLog::GetLogIfAllCategoriesSet(POSIX_LOG_PROCESS));
   LLDB_LOG(log, "pid {0}", GetID());
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-11-11 Thread Jason Molenda via lldb-commits


On 11/09/19 12:41 PM, Jan Kratochvil   wrote: 
> 
> On Sat, 09 Nov 2019 03:25:51 +0100, Jason Molenda via lldb-commits wrote:
> > I'm switching the default for at least the weekend via 
> > 60ab30ebce833c87bd4776f67cd9a82fe162ef9c / 
> > https://reviews.llvm.org/rG60ab30ebce83 so the bots aren't failing because 
> > of this, we can all look into this next week. I think the best solution is 
> > to get lldb to fall back to p/P if g/G are not supported (which we need to 
> > talk to some targets), and disable debugserver's g/G packet support until I 
> > can debug where the bug is over there.
> > 
> > I'm still concerned about some of the macos CI bots which use the installed 
> > debugservers, which will continue to have this g/G bug for a while, we'll 
> > figure all that out next week.
> 
> Linux Fedora 30 x86_64:
> d162e02cee74a3dbbfb1317fa9749f5e18610282
> 
>  File 
> "/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py",
>  line 93, in test
>  self.assertEqual(rax, 0xffe03c778278)
> AssertionError: 0 != 18446743937285063288L
> 



Hi Jan, thanks for letting me know. Would it be possible to run the test case 
with tracing enabled? On my mac I use the lldb-dotest command, like

./lldb-dotest -t -v -p TestNoGPacketSupported.py

I wrote the test case so it will print all of the packets when trace mode is 
enabled, I can probably tell what's going on from that.



I'm surprised there's a difference of behavior here, maybe I made a mistake 
when I changed the default Friday evening. This is lldb talking to a fake gdb 
RSP stub replaying packets - it shouldn't matter if lldb itself is running on a 
mac or on a linux system, unless I'm forgetting something.

Thanks!

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


[Lldb-commits] [PATCH] D69931: Add cmake variables to specify a python framework to ship with lldb

2019-11-11 Thread António Afonso via Phabricator via lldb-commits
aadsm added a comment.

> The proposed path in this patch, -rpath "@loader_path/../../../", uses the 
> @loader_path expansion which is the directory containing the binary that the 
> load command is in (in this case liblldb's directory). Popping 3 directories 
> up from that is likely not sane in most build configurations, but if it works 
> for you meh...

This is exactly what Apple ships with Xcode today:

  $ otool -l 
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/liblldbPluginScriptInterpreterPython3.dylib
 | grep RPATH -A 2
cmd LC_RPATH
cmdsize 72
   path @loader_path/../../../../../../../../Library/Frameworks/ 
(offset 12)
  --
cmd LC_RPATH
cmdsize 72
   path @loader_path/../../../../../Developer/Library/Frameworks/ 
(offset 12)
  --
cmd LC_RPATH
cmdsize 72
   path @loader_path/../../../../Developer/Library/Frameworks/ (offset 
12)
  --
cmd LC_RPATH
cmdsize 48
   path @loader_path/../../../../Frameworks (offset 12)
  --
cmd LC_RPATH
cmdsize 40
   path @loader_path/../../../ (offset 12)
  
  $ otool -L 
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/Python3
  
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/Python3:
@rpath/Python3.framework/Versions/3.7/Python3 (compatibility version 
3.7.0, current version 3.7.0)

But they build liblldbPluginScriptInterpreterPython3 as a dylib instead of 
statically inside liblldb (so that they can have both 2.7 and 3.7).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931



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


[Lldb-commits] [PATCH] D69931: Add cmake variables to specify a python framework to ship with lldb

2019-11-11 Thread António Afonso via Phabricator via lldb-commits
aadsm updated this revision to Diff 228634.
aadsm added a comment.

Updating to only add an rpath that points to the directory where 
LLDB.frameworks gets installed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931

Files:
  lldb/cmake/modules/LLDBFramework.cmake


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,7 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,7 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-11-11 Thread Jan Kratochvil via lldb-commits
Hi Jason,

On Mon, 11 Nov 2019 02:04:55 +0100, Jason Molenda wrote:
> ./lldb-dotest -t -v -p TestNoGPacketSupported.py

Linux Fedora 30 x86_64
6ef63638cb8bac243e0e59cec66a19c57b79e351


Thanks,
Jan
/usr/bin/python /home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py 
--arch=x86_64 -s 
/home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
CXXFLAGS -u CFLAGS --executable 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
 -t -v -p TestNoGPacketSupported.py
/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py --arch=x86_64 -s 
/home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
CXXFLAGS -u CFLAGS --executable 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
 -t -v -p TestNoGPacketSupported.py
LLDB library dir: /home/jkratoch/redhat/llvm-monorepo-clangassert/bin
LLDB import library dir: /home/jkratoch/redhat/llvm-monorepo-clangassert/bin
lldb version 10.0.0 (https://github.com/llvm/llvm-project.git revision 
42e88995e62525a69b0d4b1780ae19649a5ff3b4)
  clang revision 6ef63638cb8bac243e0e59cec66a19c57b79e351
  llvm revision 6ef63638cb8bac243e0e59cec66a19c57b79e351
Libc++ tests will not be run because: Unable to find libc++ installation
Skipping following debug info categories: ['dsym', 'gmodules']

Session logs for test failures/errors/unexpected successes will go into 
directory '/home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces'
Command invoked: /home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py 
--arch=x86_64 -s 
/home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
CXXFLAGS -u CFLAGS --executable 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
/home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
 -t -v -p TestNoGPacketSupported.py
compiler=/home/jkratoch/redhat/llvm-monorepo-clangassert/bin/clang-10

Configuration: arch=x86_64 
compiler=/home/jkratoch/redhat/llvm-monorepo-clangassert/bin/clang-10
--
Collected 1 test

Change dir to: 
/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client
1: test (TestNoGPacketSupported.TestNoGPacketSupported) ... runCmd: settings 
set symbols.enable-external-lookup false
output: 

runCmd: settings set plugin.process.gdb-remote.packet-timeout 60
output: 

runCmd: settings set symbols.clang-modules-cache-path 
"/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex/module-cache-lldb"
output: 

runCmd: settings set use-color false
output: 

runCmd: settings set target.env-vars LD_LIBRARY_PATH=
output: 

runCmd: log enable gdb-remote packets
output: 

runCmd: log enable gdb-remote packets
output: 

Adding tearDown hook: lambda: self.runCmd("log disable 
gdb-remote packets"))


python   <   1> send packet: +
python   history[1] tid=0x1d5a <   1> send packet: +
python   <  19> send packet: $QStartNoAckMode#b0
python   <   1> read packet: +
python   <   6> read packet: $OK#9a
python   <   1> send packet: +
python   <  45> send packet: 
$qSupported:xmlRegisters=i386,arm,mips,arc#74
python   <  57> read packet: 
$qXfer:features:read+;PacketSize=3fff;QStartNoAckMode+#86
python   <  26> send packet: $QThreadSuffixSupported#e4
python   <   4> read packet: $#00
python   <  27> send packet: $QListThreadsInStopReply#21
python   <   4> read packet: $#00
python   <  13> send packet: $qHostInfo#9b
python   <  28> read packet: $ptrsize:8;endian:little;#30
python   <  10> send packet: $vCont?#49
python   <   4> read packet: $#00
python   <  27> send packet: $qVAttachOrWaitSupported#38
python   <   4> read packet: $#00
python   <  23> send packet: $QEnableErrorStrings#8c
python   <   

[Lldb-commits] [PATCH] D70022: [lldb] [Process/NetBSD] Improve threading support

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

The code seems reasonable, but I think it would be good include the set of 
tests which this patch is supposed to fix into the patch itself. (And same for 
other patches too.) There's also some functionality here that's probably not 
tested by any of our existing tests, so it would be good to have separate 
netbsd-specific tests too -- I'm mainly thinking of the code which mangles the 
resume actions into forms suitable for netbsd -- perhaps a test where one 
attempts to send two different signals to two threads (and gets an error in 
return), or when two (but not all) threads get the same signal.




Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:454-455
+case eStateStopped:
+  if (action->signal != LLDB_INVALID_SIGNAL_NUMBER)
+return Status("Passing signal to suspended thread unsupported");
+

Maybe this could be an assert ?



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:477-481
+signal = siginfo->psi_siginfo.si_signo;
+  }
+
+  ret = PtraceWrapper(PT_CONTINUE, GetID(), reinterpret_cast(1),
+  signal);

(just curious) so you need to pass the signal both in the siginfo struct, and 
also to the PT_CONTINUE operation?


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

https://reviews.llvm.org/D70022



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


[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c:1-23
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;

Maybe simplify this and remove the threads and stuff?



Comment at: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test:5
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && 
!dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %s %t.out 2>&1 | FileCheck %s

You should use %clang_host now. Are you sure that this even works on current 
master?


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

https://reviews.llvm.org/D70050



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


[Lldb-commits] [PATCH] D69931: Add cmake variables to specify a python framework to ship with lldb

2019-11-11 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.

This seems reasonable to me.

> path @loader_path/../../../../../../../../Library/Frameworks/

LOL :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931



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


[Lldb-commits] [PATCH] D70060: [lldb] [Process/NetBSD] Use PT_STOP to stop the process

2019-11-11 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.

lgtm


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

https://reviews.llvm.org/D70060



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


[Lldb-commits] [PATCH] D70060: [lldb] [Process/NetBSD] Use PT_STOP to stop the process

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Does this have any functional difference that would be useful to test?


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

https://reviews.llvm.org/D70060



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


[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny marked 2 inline comments as done.
mgorny added inline comments.



Comment at: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c:1-23
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;

labath wrote:
> Maybe simplify this and remove the threads and stuff?
Threads are intentional since new thread handler copies dbregs per the other 
patch. This makes sure that new thread handler will not crash when it is unable 
to set dbregs.



Comment at: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test:5
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && 
!dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %s %t.out 2>&1 | FileCheck %s

labath wrote:
> You should use %clang_host now. Are you sure that this even works on current 
> master?
I have to admit that I'm at ~Oct 31 in my checkout. I've tried using 
`%clang_host` but it failed with `fg` saying that there is no job control.


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

https://reviews.llvm.org/D70050



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


[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c:1-23
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;

mgorny wrote:
> labath wrote:
> > Maybe simplify this and remove the threads and stuff?
> Threads are intentional since new thread handler copies dbregs per the other 
> patch. This makes sure that new thread handler will not crash when it is 
> unable to set dbregs.
Hang on, isn't this test about what happens when you *cannot* set watchpoints? 
In that case there should be nothing to copy the dbregs from, right?



Comment at: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test:5
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && 
!dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %s %t.out 2>&1 | FileCheck %s

mgorny wrote:
> labath wrote:
> > You should use %clang_host now. Are you sure that this even works on 
> > current master?
> I have to admit that I'm at ~Oct 31 in my checkout. I've tried using 
> `%clang_host` but it failed with `fg` saying that there is no job control.
%clang_host was added *on* Oct 31, so maybe you need to sync a bit further... :)


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

https://reviews.llvm.org/D70050



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


[Lldb-commits] [PATCH] D70022: [lldb] [Process/NetBSD] Improve threading support

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny marked 2 inline comments as done.
mgorny added a comment.

Well, are there any LLDB commands that can actually cause such an event to 
happen? I haven't been able to find one to send a signal to thread in the first 
place.




Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:454-455
+case eStateStopped:
+  if (action->signal != LLDB_INVALID_SIGNAL_NUMBER)
+return Status("Passing signal to suspended thread unsupported");
+

labath wrote:
> Maybe this could be an assert ?
Well, looking at the gdb protocol, it probably can't happen indeed. However, 
when I was writing that I assumed 'ResumeActionList is the limit', and didn't 
want to assert-crash if things were extended in the future.



Comment at: lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp:477-481
+signal = siginfo->psi_siginfo.si_signo;
+  }
+
+  ret = PtraceWrapper(PT_CONTINUE, GetID(), reinterpret_cast(1),
+  signal);

labath wrote:
> (just curious) so you need to pass the signal both in the siginfo struct, and 
> also to the PT_CONTINUE operation?
Yes. The former is not strictly necessary but the latter is obligatory.


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

https://reviews.llvm.org/D70022



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


[Lldb-commits] [PATCH] D70022: [lldb] [Process/NetBSD] Improve threading support

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D70022#1740388 , @mgorny wrote:

> Well, are there any LLDB commands that can actually cause such an event to 
> happen? I haven't been able to find one to send a signal to thread in the 
> first place.


You can make a gdb-remote test which sends the appropriate packets directly.


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

https://reviews.llvm.org/D70022



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


[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c:1-23
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;

labath wrote:
> mgorny wrote:
> > labath wrote:
> > > Maybe simplify this and remove the threads and stuff?
> > Threads are intentional since new thread handler copies dbregs per the 
> > other patch. This makes sure that new thread handler will not crash when it 
> > is unable to set dbregs.
> Hang on, isn't this test about what happens when you *cannot* set 
> watchpoints? In that case there should be nothing to copy the dbregs from, 
> right?
Hmm... or is it that you're testing that the act of trying to copy this 
"nothing" works? In that case, this might be fine, but it'd probably be worth 
mentioning this in the test case.


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

https://reviews.llvm.org/D70050



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


[Lldb-commits] [PATCH] D70060: [lldb] [Process/NetBSD] Use PT_STOP to stop the process

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

Not that I know of. The main difference is how it behaves on a stopped process 
but I don't think we're ever issuing it on one.


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

https://reviews.llvm.org/D70060



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


[Lldb-commits] [PATCH] D70050: [lldb] [test] Add a test for watchpoint set error handling on NetBSD

2019-11-11 Thread Michał Górny via Phabricator via lldb-commits
mgorny marked 2 inline comments as done.
mgorny added inline comments.



Comment at: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c:1-23
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;

labath wrote:
> labath wrote:
> > mgorny wrote:
> > > labath wrote:
> > > > Maybe simplify this and remove the threads and stuff?
> > > Threads are intentional since new thread handler copies dbregs per the 
> > > other patch. This makes sure that new thread handler will not crash when 
> > > it is unable to set dbregs.
> > Hang on, isn't this test about what happens when you *cannot* set 
> > watchpoints? In that case there should be nothing to copy the dbregs from, 
> > right?
> Hmm... or is it that you're testing that the act of trying to copy this 
> "nothing" works? In that case, this might be fine, but it'd probably be worth 
> mentioning this in the test case.
Actually, since the whole dbreg support is rather stateless at the moment, we 
just unconditionally copy dbregs. I suppose this needs to be fixed, and now I 
see that my other patch misses error handling as well. However, the main point 
for this test is to prevent regressions, and this is a potential programmer's 
mistake.



Comment at: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test:5
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && 
!dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error 
false' -s %s %t.out 2>&1 | FileCheck %s

labath wrote:
> mgorny wrote:
> > labath wrote:
> > > You should use %clang_host now. Are you sure that this even works on 
> > > current master?
> > I have to admit that I'm at ~Oct 31 in my checkout. I've tried using 
> > `%clang_host` but it failed with `fg` saying that there is no job control.
> %clang_host was added *on* Oct 31, so maybe you need to sync a bit further... 
> :)
Ok, I'll try.


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

https://reviews.llvm.org/D70050



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


[Lldb-commits] [PATCH] D70070: [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variable

2019-11-11 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor created this revision.
teemperor added reviewers: labath, davide.
teemperor added a project: Upstreaming LLDB's downstream patches.
Herald added subscribers: lldb-commits, JDevlieghere.
Herald added a project: LLDB.

swift-lldb currently has to patch the ExpressionKind enum to add support for 
Swift expressions. If we implement LLVM's RTTI
with a static ID variable instead of a centralised enum we can drop that patch.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D70070

Files:
  lldb/include/lldb/Expression/Expression.h
  lldb/include/lldb/Expression/FunctionCaller.h
  lldb/include/lldb/Expression/LLVMUserExpression.h
  lldb/include/lldb/Expression/UserExpression.h
  lldb/include/lldb/Expression/UtilityFunction.h
  lldb/source/Expression/Expression.cpp
  lldb/source/Expression/FunctionCaller.cpp
  lldb/source/Expression/LLVMUserExpression.cpp
  lldb/source/Expression/UserExpression.cpp
  lldb/source/Expression/UtilityFunction.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.h

Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.h
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.h
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.h
@@ -33,11 +33,14 @@
 /// simply provide a way to push a function into the target for the debugger
 /// to call later on.
 class ClangUtilityFunction : public UtilityFunction {
+  // LLVM RTTI support
+  static char ID;
+
 public:
-  /// LLVM-style RTTI support.
-  static bool classof(const Expression *E) {
-return E->getKind() == eKindClangUtilityFunction;
+  bool isA(const void *ClassID) const override {
+return ClassID == &ID || UtilityFunction::isA(ClassID);
   }
+  static bool classof(const Expression *obj) { return obj->isA(&ID); }
 
   class ClangUtilityFunctionHelper : public ClangExpressionHelper {
   public:
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
@@ -31,6 +31,8 @@
 
 using namespace lldb_private;
 
+char ClangUtilityFunction::ID;
+
 /// Constructor
 ///
 /// \param[in] text
@@ -40,7 +42,7 @@
 /// The name of the function, as used in the text.
 ClangUtilityFunction::ClangUtilityFunction(ExecutionContextScope &exe_scope,
const char *text, const char *name)
-: UtilityFunction(exe_scope, text, name, eKindClangUtilityFunction) {
+: UtilityFunction(exe_scope, text, name) {
   m_function_text.assign(ClangExpressionSourceCode::g_expression_prefix);
   if (text && text[0])
 m_function_text.append(text);
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
@@ -38,11 +38,14 @@
 /// the objects needed to parse and interpret or JIT an expression.  It uses
 /// the Clang parser to produce LLVM IR from the expression.
 class ClangUserExpression : public LLVMUserExpression {
+  // LLVM RTTI support
+  static char ID;
+
 public:
-  /// LLVM-style RTTI support.
-  static bool classof(const Expression *E) {
-return E->getKind() == eKindClangUserExpression;
+  bool isA(const void *ClassID) const override {
+return ClassID == &ID || LLVMUserExpression::isA(ClassID);
   }
+  static bool classof(const Expression *obj) { return obj->isA(&ID); }
 
   enum { kDefaultTimeout = 50u };
 
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
@@ -62,13 +62,15 @@
 
 using namespace lldb_private;
 
+char ClangUserExpression::ID;
+
 ClangUserExpression::ClangUserExpression(
 ExecutionContextScope &exe_scope, llvm::StringRef expr,
 llvm::StringRef prefix, lldb::LanguageType language,
 ResultType desired_type, const EvaluateExpressionOptions &options,
 ValueObject *ctx_obj)
 : LLVMUserExpression(exe_scope, expr, prefix, language, desired_type,
- options, eKindClangUserExpression),
+ options),
   m_type_system_helper(*m_target_wp.lock(), options.GetExecutionPolicy() ==

[Lldb-commits] [PATCH] D70070: [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variable

2019-11-11 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.

Swift aside, I think it's also good that the generic Expression class does not 
need to know about the various kinds of expressions that the Clang Expression 
parser plugin wants to invent.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D70070



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


[Lldb-commits] [PATCH] D70074: [lldb][NFC] Remove unused CompilerType::IsPossibleCPlusPlusDynamicType

2019-11-11 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment.

(Just leaving this here to have it in my patch queue until the automerger bot 
is back from the dead).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D70074



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


[Lldb-commits] [PATCH] D70074: [lldb][NFC] Remove unused CompilerType::IsPossibleCPlusPlusDynamicType

2019-11-11 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor created this revision.
Herald added subscribers: lldb-commits, JDevlieghere.
Herald added a project: LLDB.

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D70074

Files:
  lldb/include/lldb/Symbol/CompilerType.h


Index: lldb/include/lldb/Symbol/CompilerType.h
===
--- lldb/include/lldb/Symbol/CompilerType.h
+++ lldb/include/lldb/Symbol/CompilerType.h
@@ -108,11 +108,6 @@
 
   bool IsPolymorphicClass() const;
 
-  bool
-  IsPossibleCPlusPlusDynamicType(CompilerType *target_type = nullptr) const {
-return IsPossibleDynamicType(target_type, true, false);
-  }
-
   bool IsPossibleDynamicType(CompilerType *target_type, // Can pass nullptr
  bool check_cplusplus, bool check_objc) const;
 


Index: lldb/include/lldb/Symbol/CompilerType.h
===
--- lldb/include/lldb/Symbol/CompilerType.h
+++ lldb/include/lldb/Symbol/CompilerType.h
@@ -108,11 +108,6 @@
 
   bool IsPolymorphicClass() const;
 
-  bool
-  IsPossibleCPlusPlusDynamicType(CompilerType *target_type = nullptr) const {
-return IsPossibleDynamicType(target_type, true, false);
-  }
-
   bool IsPossibleDynamicType(CompilerType *target_type, // Can pass nullptr
  bool check_cplusplus, bool check_objc) const;
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [lldb] 0877dd1 - [Driver] Force llvm to install its handlers before lldb's

2019-11-11 Thread Pavel Labath via lldb-commits

On 09/11/2019 03:05, v...@apple.com wrote:




On Nov 8, 2019, at 1:17 AM, Pavel Labath  wrote:

On 08/11/2019 01:33, via lldb-commits wrote:

Hey JF, Pavel,
We're still seeing crashes due to SIGPIPE on some lldb bots. This workaround in 
the lldb driver is insufficient, because liblldb.dylib may install its own a 
fresh set of llvm signal handlers (the `NumRegisteredSignals` global is not 
shared by all images loaded in a process). Here is a trace that illustrates the 
issue: https://gist.github.com/vedantk/2d0cc1df9bea9f0fa74ee101d240b82c.
I think we should fix this by changing llvm's default behavior: let's have it 
ignore SIGPIPE. Driver programs (like clang, dwarfdump, etc.) can then opt-in 
to exiting when SIGPIPE is received. Wdyt?


Ah, yes.. I should've realized that wasn't enough.

I agree (and I've alluded to this in the past) that changing the llvm behavior 
is the best option, though ideally, I'd take this a step further, and have llvm 
avoid installing *any* signal handlers by default.

This kind of race is not just limited to SIGPIPE. Other signals suffer from the 
same issues too, it's just that the manifestation of that is more subtle.

lldb and liblldb are still racing in who sets the SIGSEGV (etc.) handlers last. 
Since the main effect of those handlers is to produce a backtrace and exit, you 
won't notice this most of the time. But another effect of these handlers is to 
run the RemoveFileOnSignal actions, and so the set of files removed might 
differ since the two lists of files to delete are independent too.

(BTW, the fact that this is two copies of llvm racing with each other here is 
unfortunate but irrelevant for this discussion -- the same kind of problem 
would occur if we had llvm and some other entity both trying to handle the same 
signals.)


One wrinkle is that the two copies of llvm will track different sets of files 
to remove on a signal. In practice, this doesn't seem to be an issue. But the 
current situation is that if the lldb process gets a SIGINT, any 
files-to-be-removed registered by liblldb get removed, but any 
files-to-be-removed registered by the lldb driver stick around.



I think the right behavior for the llvm *library* should be to not install 
*any* signal handlers by default. Instead it should expose some API like 
`runAbnormalExitActions()`, which it's *users* can invoke from a signal 
handler, if they choose so.

Then, the client programs can opt into installing the signal handlers and 
calling this function. This can be done as a part of InitLLVM, and it can be 
the default behavior of InitLLVM. The lldb driver can then pass some flag to 
InitLLVM to disable this handling, or it can just continue to override it after 
the fact, like it does now.


One advantage of this approach is that existing llvm tools without custom 
signal handling wouldn't have to change.

To make this work, the dylib would need to install an interrupt handler that 1) 
runs llvm::runAbnormalExitActions() to clean up files, then 2) locates & runs 
the lldb driver's handler (to do `GetDebugger().DispatchInputInterrupt()`).

And we couldn't use a static initializer to do it, because *then* 
liblldb.dylib's handler would get installed before the lldb driver's. I think 
this approach necessitates a special entry point into the dylib that just 
installs handlers.


That's *almost* what I was thinking. The main difference is that I 
didn't want liblldb to be installing the signal handlers (as it is also 
a library, and I don't think *any* library should be doing that by default).
Instead I'd expose an SB api to run the cleanup actions 
(SBHostOS::RunAbnormalExitActions() ?), and leave the signal 
installation to the lldb driver, whose handler can then call the SB 
function.
However, all of this is only needed if we _really_ care that the cleanup 
actions inside liblldb get actually run. I'm not sure if that's the case 
right now.






Some alternatives include:
- Add a static initializer to liblldb.dylib that copies the workaround in the 
driver. This should work fine, but it's a duct tape on top of a bandaid.
- Have the dynamic linker coalesce all copies of `NumRegisteredSignals` in a 
process. This would incur an app launch time hit on iOS (where libllvm is hot 
code), and it doesn't seem very portable.


A third option might be to link liblldb and the lldb driver to libllvm 
dynamically. That would solve this problem by not having two copies of llvm 
around, but it would also come with some runtime and binary size costs...


Yeah, that might be too big a hammer.

I just talked to Jonas about it offline and both of us think we should just 
make llvm's current SIGPIPE handling opt-in, as (imo) it's a lot simpler than 
the alternatives we've mentioned so far. @Pavel it sounded like you were ok 
with this in principle -- anyone have any objections?


I think it's "acceptable", but I'm not really thrilled with it, as it 
still seems fairly bandaid-y. I'm pretty sure we'll run into ot

Re: [Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-11-11 Thread Jason Molenda via lldb-commits
Thanks! 

lldb is trying to resume execution for some reason. I wonder if the T11 as the 
stop reason is causing problems, I just did it at random. I'll try changing the 
test to use a T02 stop reason. Baffled as to the difference in behavior, but 
we'll see if this matters.

On 11/10/19 10:32 PM, Jan Kratochvil   wrote: 
> 
> Hi Jason,
> 
> On Mon, 11 Nov 2019 02:04:55 +0100, Jason Molenda wrote:
> > ./lldb-dotest -t -v -p TestNoGPacketSupported.py
> 
> Linux Fedora 30 x86_64
> 6ef63638cb8bac243e0e59cec66a19c57b79e351
> 
> 
> Thanks,
> Jan
> 
> /usr/bin/python /home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py 
> --arch=x86_64 -s 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
> CXXFLAGS -u CFLAGS --executable 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
>  -t -v -p 
> TestNoGPacketSupported.py/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py
>  --arch=x86_64 -s 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
> CXXFLAGS -u CFLAGS --executable 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
>  -t -v -p TestNoGPacketSupported.pyLLDB library dir: 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/binLLDB import library dir: 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/binlldb version 10.0.0 
> (https://github.com/llvm/llvm-project.git revision 
> 42e88995e62525a69b0d4b1780ae19649a5ff3b4) clang revision 
> 6ef63638cb8bac243e0e59cec66a19c57b79e351 llvm revision 
> 6ef63638cb8bac243e0e59cec66a19c57b79e351Libc++ tests will not be run because: 
> Unable to find libc++ installationSkipping following debug info categories: 
> ['dsym', 'gmodules']Session logs for test failures/errors/unexpected 
> successes will go into directory 
> '/home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces'Command 
> invoked: /home/jkratoch/redhat/llvm-monorepo/lldb/test/API/dotest.py 
> --arch=x86_64 -s 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/lldb-test-traces -S nm -u 
> CXXFLAGS -u CFLAGS --executable 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/lldb --compiler 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/clang --dsymutil 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/dsymutil --filecheck 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/./bin/FileCheck --env 
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --build-dir 
> /home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex
>  -t -v -p 
> TestNoGPacketSupported.pycompiler=/home/jkratoch/redhat/llvm-monorepo-clangassert/bin/clang-10Configuration:
>  arch=x86_64 
> compiler=/home/jkratoch/redhat/llvm-monorepo-clangassert/bin/clang-10--Collected
>  1 testChange dir to: 
> /home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client1:
>  test (TestNoGPacketSupported.TestNoGPacketSupported) ... runCmd: settings 
> set symbols.enable-external-lookup falseoutput: runCmd: settings set 
> plugin.process.gdb-remote.packet-timeout 60output: runCmd: settings set 
> symbols.clang-modules-cache-path 
> "/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/lldb-test-build.noindex/module-cache-lldb"output:
>  runCmd: settings set use-color falseoutput: runCmd: settings set 
> target.env-vars LD_LIBRARY_PATH=output: runCmd: log enable gdb-remote 
> packetsoutput: runCmd: log enable gdb-remote packetsoutput: Adding tearDown 
> hook: lambda: self.runCmd("log disable gdb-remote packets"))python < 1 
> target="1"> send packet: +python history[1] tid=0x1d5a < 1 target="1"> send 
> packet: +python < 19 target="1"> send packet: $QStartNoAckMode#b0python < 1 
> target="1"> read packet: +python < 6 target="1"> read packet: $OK#9apython < 
> 1 target="1"> send packet: +python < 45 target="1"> send packet: 
> $qSupported:xmlRegisters=i386,arm,mips,arc#74python < 57 target="1"> read 
> packet: $qXfer:features:read+;PacketSize=3fff;QStartNoAckMode+#86python < 26 
> target="1"> send packet: $QThreadSuffixSupported#e4python < 4 target="1"> 
> read packet: $#00python < 27 target="1"> send packet: 
> $QListThreadsInStopReply#21pytho

[Lldb-commits] [lldb] 135a493 - Fix TestNoGPacketSupported on linux

2019-11-11 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2019-11-11T17:29:48+01:00
New Revision: 135a493f34561219d67251b58a482cd3fc6416b9

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

LOG: Fix TestNoGPacketSupported on linux

The mock server pretends the process stopped with signal 17, which is
SIGCHLD on linux. This causes lldb to resume to process, utterly
confusing the test. Lldb probably shouldn't resume in this case, but for
now this issue can be fixed by changing the signal number to 2, which is
SIGINT just about anywhere.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py
 
b/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py
index 989684c62229..c9404d41924a 100644
--- 
a/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py
+++ 
b/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py
@@ -26,10 +26,10 @@ class TestNoGPacketSupported(GDBRemoteTestBase):
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):
-return 
"T11thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:7882773ce0ff;01:1122334455667788;03:00bc01000100;"
+return 
"T02thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:7882773ce0ff;01:1122334455667788;03:00bc01000100;"
 
 def threadStopInfo(self, threadnum):
-return 
"T11thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:7882773ce0ff;01:1122334455667788;03:00bc01000100;"
+return 
"T02thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:7882773ce0ff;01:1122334455667788;03:00bc01000100;"
 
 def writeRegisters(self):
 return "E02"



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


Re: [Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-11-11 Thread Pavel Labath via lldb-commits

On 09/11/2019 21:41, Jan Kratochvil via lldb-commits wrote:

On Sat, 09 Nov 2019 03:25:51 +0100, Jason Molenda via lldb-commits wrote:

I'm switching the default for at least the weekend via 
60ab30ebce833c87bd4776f67cd9a82fe162ef9c / 
https://reviews.llvm.org/rG60ab30ebce83 so the bots aren't failing because of 
this, we can all look into this next week.  I think the best solution is to get 
lldb to fall back to p/P if g/G are not supported (which we need to talk to 
some targets), and disable debugserver's g/G packet support until I can debug 
where the bug is over there.

I'm still concerned about some of the macos CI bots which use the installed 
debugservers, which will continue to have this g/G bug for a while, we'll 
figure all that out next week.


Linux Fedora 30 x86_64:
d162e02cee74a3dbbfb1317fa9749f5e18610282

   File 
"/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py",
 line 93, in test
 self.assertEqual(rax, 0xffe03c778278)
AssertionError: 0 != 18446743937285063288L



This should be fixed with 135a493f3456.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] a14eb8f - lldb: Fix some -Wdeprecated-copy warnings

2019-11-11 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2019-11-11T17:55:49+01:00
New Revision: a14eb8f47d43c701651ad59f49167a614a8c9773

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

LOG: lldb: Fix some -Wdeprecated-copy warnings

gcc-9 started warning when a class defined a copy constructor without a
copy assignment operator (or vice-versa).

This fixes those warnings by deleting the other special member too
(after verifying it doesn't do anything non-trivial).

Added: 


Modified: 
lldb/include/lldb/Interpreter/OptionValue.h
lldb/include/lldb/Symbol/Declaration.h
lldb/include/lldb/Symbol/SymbolContext.h
lldb/include/lldb/Utility/ArchSpec.h
lldb/include/lldb/Utility/Broadcaster.h
lldb/include/lldb/Utility/FileSpec.h
lldb/include/lldb/Utility/Flags.h
lldb/include/lldb/Utility/Scalar.h
lldb/include/lldb/Utility/Status.h
lldb/source/Symbol/SymbolContext.cpp
lldb/source/Utility/ArchSpec.cpp
lldb/source/Utility/Broadcaster.cpp
lldb/source/Utility/FileSpec.cpp
lldb/source/Utility/Scalar.cpp
lldb/source/Utility/Status.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/OptionValue.h 
b/lldb/include/lldb/Interpreter/OptionValue.h
index 9fc18551c26a..734c92b4bcad 100644
--- a/lldb/include/lldb/Interpreter/OptionValue.h
+++ b/lldb/include/lldb/Interpreter/OptionValue.h
@@ -61,10 +61,6 @@ class OptionValue {
   OptionValue()
   : m_callback(nullptr), m_baton(nullptr), m_value_was_set(false) {}
 
-  OptionValue(const OptionValue &rhs)
-  : m_callback(rhs.m_callback), m_baton(rhs.m_baton),
-m_value_was_set(rhs.m_value_was_set) {}
-
   virtual ~OptionValue() = default;
 
   // Subclasses should override these functions

diff  --git a/lldb/include/lldb/Symbol/Declaration.h 
b/lldb/include/lldb/Symbol/Declaration.h
index 63798f883e5f..4b8ece02f9c7 100644
--- a/lldb/include/lldb/Symbol/Declaration.h
+++ b/lldb/include/lldb/Symbol/Declaration.h
@@ -55,16 +55,6 @@ class Declaration {
   {
   }
 
-  /// Construct with a reference to another Declaration object.
-  Declaration(const Declaration &rhs)
-  : m_file(rhs.m_file), m_line(rhs.m_line)
-#ifdef LLDB_ENABLE_DECLARATION_COLUMNS
-,
-m_column(rhs.m_column)
-#endif
-  {
-  }
-
   /// Construct with a pointer to another Declaration object.
   Declaration(const Declaration *decl_ptr)
   : m_file(), m_line(0)

diff  --git a/lldb/include/lldb/Symbol/SymbolContext.h 
b/lldb/include/lldb/Symbol/SymbolContext.h
index 76ec1a7de68e..34735ab95578 100644
--- a/lldb/include/lldb/Symbol/SymbolContext.h
+++ b/lldb/include/lldb/Symbol/SymbolContext.h
@@ -84,18 +84,6 @@ class SymbolContext {
 
   ~SymbolContext();
 
-  /// Assignment operator.
-  ///
-  /// Copies the address value from another SymbolContext object \a rhs into
-  /// \a this object.
-  ///
-  /// \param[in] rhs
-  /// A const SymbolContext object reference to copy.
-  ///
-  /// \return
-  /// A const SymbolContext object reference to \a this.
-  const SymbolContext &operator=(const SymbolContext &rhs);
-
   /// Clear the object's state.
   ///
   /// Resets all pointer members to nullptr, and clears any class objects to

diff  --git a/lldb/include/lldb/Utility/ArchSpec.h 
b/lldb/include/lldb/Utility/ArchSpec.h
index 3bfc988abf0b..bd8c421c3bfc 100644
--- a/lldb/include/lldb/Utility/ArchSpec.h
+++ b/lldb/include/lldb/Utility/ArchSpec.h
@@ -258,13 +258,6 @@ class ArchSpec {
   /// Destructor.
   ~ArchSpec();
 
-  /// Assignment operator.
-  ///
-  /// \param[in] rhs another ArchSpec object to copy.
-  ///
-  /// \return A const reference to this object.
-  const ArchSpec &operator=(const ArchSpec &rhs);
-
   /// Returns true if the OS, vendor and environment fields of the triple are
   /// unset. The triple is expected to be normalized
   /// (llvm::Triple::normalize).

diff  --git a/lldb/include/lldb/Utility/Broadcaster.h 
b/lldb/include/lldb/Utility/Broadcaster.h
index fe4d1ca479b8..ead597d626d7 100644
--- a/lldb/include/lldb/Utility/Broadcaster.h
+++ b/lldb/include/lldb/Utility/Broadcaster.h
@@ -65,7 +65,6 @@ class BroadcastEventSpec {
   }
 
   bool operator<(const BroadcastEventSpec &rhs) const;
-  BroadcastEventSpec &operator=(const BroadcastEventSpec &rhs);
 
 private:
   ConstString m_broadcaster_class;

diff  --git a/lldb/include/lldb/Utility/FileSpec.h 
b/lldb/include/lldb/Utility/FileSpec.h
index 50ad1f1600d8..53b0a9c08699 100644
--- a/lldb/include/lldb/Utility/FileSpec.h
+++ b/lldb/include/lldb/Utility/FileSpec.h
@@ -91,17 +91,6 @@ class FileSpec {
 
   bool FileEquals(const FileSpec &other) const;
 
-  /// Assignment operator.
-  ///
-  /// Makes a copy of the uniqued directory and filename strings from \a rhs.
-  ///
-  /// \param[in] rhs
-  /// A const FileSpec object reference to assign to

[Lldb-commits] [PATCH] D69931: Add cmake variables to specify a python framework to ship with lldb

2019-11-11 Thread Shoaib Meenai via Phabricator via lldb-commits
smeenai added a comment.

Commit message needs to be updated.




Comment at: lldb/cmake/modules/LLDBFramework.cmake:124
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH

You may wanna add the reason for this to the comment as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931



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


[Lldb-commits] [PATCH] D70070: [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variable

2019-11-11 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

LGTM.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D70070



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


[Lldb-commits] [PATCH] D70074: [lldb][NFC] Remove unused CompilerType::IsPossibleCPlusPlusDynamicType

2019-11-11 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.

Nice!


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D70074



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


Re: [Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-11-11 Thread Jan Kratochvil via lldb-commits
On Mon, 11 Nov 2019 17:34:45 +0100, Pavel Labath wrote:
> On 09/11/2019 21:41, Jan Kratochvil via lldb-commits wrote:
> > Linux Fedora 30 x86_64:
> > d162e02cee74a3dbbfb1317fa9749f5e18610282
> > 
> >File 
> > "/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoGPacketSupported.py",
> >  line 93, in test
> >  self.assertEqual(rax, 0xffe03c778278)
> > AssertionError: 0 != 18446743937285063288L
> 
> This should be fixed with 135a493f3456.

Confirming I also see it fixed now.


Thanks,
Jan

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


[Lldb-commits] [PATCH] D69931: Add rpath to liblldb so vendors can ship their own python framework (or others)

2019-11-11 Thread Shoaib Meenai via Phabricator via lldb-commits
smeenai added inline comments.



Comment at: lldb/cmake/modules/LLDBFramework.cmake:124
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH

smeenai wrote:
> You may wanna add the reason for this to the comment as well.
Doesn't need to be super detailed ... even just adding something like "so that 
we can find any frameworks installed beside it" should be enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931



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


[Lldb-commits] [lldb] d24bce5 - Add a testcase for .dSYM path remapping dictionaries.

2019-11-11 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-11T12:21:38-08:00
New Revision: d24bce57c3ca2414ff5e53d8f7f3f007d6a946fe

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

LOG: Add a testcase for .dSYM path remapping dictionaries.

rdar://problem/56924558

Added: 

lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile

lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py

Modified: 


Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
new file mode 100644
index ..556bda3c17d1
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
@@ -0,0 +1,8 @@
+void stop() {}
+
+int main()
+{
+  stop();
+  // Hello World!
+  return 0;
+}

diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
new file mode 100644
index ..f36a8dc1e671
--- /dev/null
+++ b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
@@ -0,0 +1,5 @@
+BOTDIR = $(BUILDDIR)/buildbot
+USERDIR = $(BUILDDIR)/user
+C_SOURCES = $(BOTDIR)/main.c
+
+include Makefile.rules

diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
new file mode 100644
index ..d13a04748672
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
@@ -0,0 +1,56 @@
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbtest as lldbtest
+import lldbsuite.test.lldbutil as lldbutil
+import os
+import unittest2
+
+
+class TestDSYMSourcePathRemapping(lldbtest.TestBase):
+
+mydir = lldbtest.TestBase.compute_mydir(__file__)
+
+def build(self):
+botdir = self.getBuildArtifact('buildbot')
+userdir = self.getBuildArtifact('user')
+inputs = self.getSourcePath('Inputs')
+lldbutil.mkdir_p(botdir)
+lldbutil.mkdir_p(userdir)
+import shutil
+for f in ['main.c']:
+shutil.copyfile(os.path.join(inputs, f), os.path.join(botdir, f))
+shutil.copyfile(os.path.join(inputs, f), os.path.join(userdir, f))
+
+super(TestDSYMSourcePathRemapping, self).build()
+
+# Remove the build sources.
+self.assertTrue(os.path.isdir(botdir))
+shutil.rmtree(botdir)
+
+# Create a plist.
+import subprocess
+dsym = self.getBuildArtifact('a.out.dSYM')
+uuid = subprocess.check_output(["/usr/bin/dwarfdump", "--uuid", dsym]
+  ).decode("utf-8").split(" ")[1]
+import re
+self.assertTrue(re.match(r'[0-9a-fA-F-]+', uuid))
+plist = os.path.join(dsym, 'Contents', 'Resources', uuid + '.plist')
+   with open(plist, 'w') as f:
+f.write('\n')
+f.write('http://www.apple.com/DTDs/PropertyList-1.0.dtd";>\n')
+   f.write('\n')
+   f.write('\n')
+   f.write('  DBGSourcePathRemapping\n')
+   f.write('  \n')
+   f.write('' + botdir + '\n')
+   f.write('' + userdir + '\n')
+   f.write('  \n')
+   f.write('\n')
+   f.write('\n')
+
+
+@skipIf(debug_info=no_match("dsym"))
+def test(self):
+self.build()
+lldbutil.run_to_name_breakpoint(self, 'main')
+self.expect("source list", substrs=["Hello World"])



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


[Lldb-commits] [lldb] da83e96 - Fix a regression in macOS-style path remapping.

2019-11-11 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-11T12:21:38-08:00
New Revision: da83e96273527a137f2ebd77cedb920180eab621

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

LOG: Fix a regression in macOS-style path remapping.

When we switched to the LLVM .debug_line parser, the .dSYM-style path
remapping logic stopped working for relative paths because of how
RemapSourceFile silently fails for relative paths. This patch both
makes the code more readable and fixes this particular bug.

One interesting thing I learned is that Module::RemapSourceFile() is a
macOS-only code path that operates on on the lldb::Module level and is
completely separate from target.source-map, which operates on a
per-Target level.

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

rdar://problem/56924558

Added: 

lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/relative.c

Modified: 

lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile

lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
index 556bda3c17d1..41a6a46c9261 100644
--- 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
+++ 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
@@ -1,8 +1,8 @@
-void stop() {}
+void relative();
 
 int main()
 {
-  stop();
-  // Hello World!
+  relative();
+  // Hello Absolute!
   return 0;
 }

diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/relative.c
 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/relative.c
new file mode 100644
index ..02331834cf21
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/relative.c
@@ -0,0 +1,5 @@
+void stop() {}
+void relative() {
+  stop();
+  // Hello Relative!
+}

diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
index f36a8dc1e671..8c82c73b13fc 100644
--- a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
+++ b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
@@ -1,5 +1,10 @@
 BOTDIR = $(BUILDDIR)/buildbot
 USERDIR = $(BUILDDIR)/user
 C_SOURCES = $(BOTDIR)/main.c
+LD_EXTRAS = $(BOTDIR)/relative.o
 
 include Makefile.rules
+
+$(EXE): relative.o
+relative.o: $(BOTDIR)/relative.c
+   cd $(BOTDIR) && $(CC) -c $(CFLAGS) -o $@ relative.c

diff  --git 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
index d13a04748672..2ee379150392 100644
--- 
a/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
+++ 
b/lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
@@ -17,7 +17,7 @@ def build(self):
 lldbutil.mkdir_p(botdir)
 lldbutil.mkdir_p(userdir)
 import shutil
-for f in ['main.c']:
+for f in ['main.c', 'relative.c']:
 shutil.copyfile(os.path.join(inputs, f), os.path.join(botdir, f))
 shutil.copyfile(os.path.join(inputs, f), os.path.join(userdir, f))
 
@@ -52,5 +52,10 @@ def build(self):
 @skipIf(debug_info=no_match("dsym"))
 def test(self):
 self.build()
-lldbutil.run_to_name_breakpoint(self, 'main')
-self.expect("source list", substrs=["Hello World"])
+
+target, process, _, _ = lldbutil.run_to_name_breakpoint(
+self, 'main')
+self.expect("source list -n main", substrs=["Hello Absolute"])
+bkpt = target.BreakpointCreateByName('relative')
+lldbutil.continue_to_breakpoint(process, bkpt)
+self.expect("source list -n relative", substrs=["Hello Relative"])

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index c982d59c2830..f43537d20200 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -179,6 +179,23 @@ ParseLLVMLineTable(lldb_private::DWARFContext &context,
   return *line_table;
 }
 
+static llvm::Optional
+GetFileByIndex(const llvm::DWARFDebugLine::Prologue &prol

[Lldb-commits] [PATCH] D70037: Fix a regression in macOS-style path remapping.

2019-11-11 Thread Adrian Prantl via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGda83e9627352: Fix a regression in macOS-style path 
remapping. (authored by aprantl).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70037

Files:
  
lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/main.c
  
lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Inputs/relative.c
  lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
  
lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -179,6 +179,23 @@
   return *line_table;
 }
 
+static llvm::Optional
+GetFileByIndex(const llvm::DWARFDebugLine::Prologue &prologue, size_t idx,
+   llvm::StringRef compile_dir, FileSpec::Style style) {
+  // Try to get an absolute path first.
+  std::string abs_path;
+  auto absolute = llvm::DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath;
+  if (prologue.getFileNameByIndex(idx, compile_dir, absolute, abs_path, style))
+return std::move(abs_path);
+
+  // Otherwise ask for a relative path.
+  std::string rel_path;
+  auto relative = llvm::DILineInfoSpecifier::FileLineInfoKind::Default;
+  if (!prologue.getFileNameByIndex(idx, compile_dir, relative, rel_path, style))
+return {};
+  return std::move(rel_path);
+}
+
 static FileSpecList ParseSupportFilesFromPrologue(
 const lldb::ModuleSP &module,
 const llvm::DWARFDebugLine::Prologue &prologue, FileSpec::Style style,
@@ -188,27 +205,12 @@
 
   const size_t number_of_files = prologue.FileNames.size();
   for (size_t idx = 1; idx <= number_of_files; ++idx) {
-std::string original_file;
-if (!prologue.getFileNameByIndex(
-idx, compile_dir,
-llvm::DILineInfoSpecifier::FileLineInfoKind::Default, original_file,
-style)) {
-  // Always add an entry so the indexes remain correct.
-  support_files.EmplaceBack();
-  continue;
-}
-
 std::string remapped_file;
-if (!prologue.getFileNameByIndex(
-idx, compile_dir,
-llvm::DILineInfoSpecifier::FileLineInfoKind::AbsoluteFilePath,
-remapped_file, style)) {
-  // Always add an entry so the indexes remain correct.
-  support_files.EmplaceBack(original_file, style);
-  continue;
-}
+if (auto file_path = GetFileByIndex(prologue, idx, compile_dir, style))
+  if (!module->RemapSourceFile(llvm::StringRef(*file_path), remapped_file))
+remapped_file = std::move(*file_path);
 
-module->RemapSourceFile(llvm::StringRef(original_file), remapped_file);
+// Unconditionally add an entry, so the indices match up.
 support_files.EmplaceBack(remapped_file, style);
   }
 
Index: lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
===
--- lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
+++ lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/TestDSYMSourcePathRemapping.py
@@ -17,7 +17,7 @@
 lldbutil.mkdir_p(botdir)
 lldbutil.mkdir_p(userdir)
 import shutil
-for f in ['main.c']:
+for f in ['main.c', 'relative.c']:
 shutil.copyfile(os.path.join(inputs, f), os.path.join(botdir, f))
 shutil.copyfile(os.path.join(inputs, f), os.path.join(userdir, f))
 
@@ -52,5 +52,10 @@
 @skipIf(debug_info=no_match("dsym"))
 def test(self):
 self.build()
-lldbutil.run_to_name_breakpoint(self, 'main')
-self.expect("source list", substrs=["Hello World"])
+
+target, process, _, _ = lldbutil.run_to_name_breakpoint(
+self, 'main')
+self.expect("source list -n main", substrs=["Hello Absolute"])
+bkpt = target.BreakpointCreateByName('relative')
+lldbutil.continue_to_breakpoint(process, bkpt)
+self.expect("source list -n relative", substrs=["Hello Relative"])
Index: lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
===
--- lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
+++ lldb/packages/Python/lldbsuite/test/macosx/DBGSourcePathRemapping/Makefile
@@ -1,5 +1,10 @@
 BOTDIR = $(BUILDDIR)/buildbot
 USERDIR = $(BUILDDIR)/user
 C_SOURCES = $(BOTDIR)/main.c
+LD_EXTRAS = $(BOTDIR)/relative.o
 
 include Makefile.rules
+
+$(EXE): relative.o
+relative.o: $(BOTDIR)/rela

[Lldb-commits] [PATCH] D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance

2019-11-11 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: lldb/include/lldb/Symbol/CompileUnit.h:169
+  /// \param[in] matching_lambda
+  /// A predicate used to evaluate each function name.
+  ///

This doesn't explain what the bool return does.


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

https://reviews.llvm.org/D69913



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


[Lldb-commits] [PATCH] D69931: Add rpath to liblldb so vendors can ship their own python framework (or others)

2019-11-11 Thread António Afonso via Phabricator via lldb-commits
aadsm updated this revision to Diff 228765.
aadsm edited the summary of this revision.
aadsm added a comment.

Clarify the point of the install_path


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931

Files:
  lldb/cmake/modules/LLDBFramework.cmake


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,8 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+# This allows frameworks (relying on @rpath) to be installed in the same 
folder and found at runtime.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,8 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+# This allows frameworks (relying on @rpath) to be installed in the same folder and found at runtime.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D69873: [lldb-vscode] support the completion request

2019-11-11 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Maybe limit the matches if posssible if that works. If you type "target 
variable " you can complete a list of all global variables everywhere 
which might be quite a few.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69873



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


[Lldb-commits] [lldb] 0cf86da - [Reproducer] Quit the debugger after generating a reproducer

2019-11-11 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2019-11-11T14:29:53-08:00
New Revision: 0cf86da1741fb1a4278dc31dfc8f1538c9186892

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

LOG: [Reproducer] Quit the debugger after generating a reproducer

Currently nothing prevents you from continuing your debug session after
generating the reproducer. This can cause the reproducer to end up in an
inconsistent state. Most of the time this doesn't matter, but I want to
prevent this from causing bugs in the future.

Added: 


Modified: 
lldb/source/Commands/CommandObjectReproducer.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectReproducer.cpp 
b/lldb/source/Commands/CommandObjectReproducer.cpp
index dc4579c20fc2..560df25b97c6 100644
--- a/lldb/source/Commands/CommandObjectReproducer.cpp
+++ b/lldb/source/Commands/CommandObjectReproducer.cpp
@@ -78,7 +78,7 @@ class CommandObjectReproducerGenerate : public 
CommandObjectParsed {
 interpreter, "reproducer generate",
 "Generate reproducer on disk. When the debugger is in capture "
 "mode, this command will output the reproducer to a directory on "
-"disk. In replay mode this command in a no-op.",
+"disk and quit. In replay mode this command in a no-op.",
 nullptr) {}
 
   ~CommandObjectReproducerGenerate() override = default;
@@ -110,7 +110,9 @@ class CommandObjectReproducerGenerate : public 
CommandObjectParsed {
 << "Please have a look at the directory to assess if you're willing to 
"
"share the contained information.\n";
 
-result.SetStatus(eReturnStatusSuccessFinishResult);
+m_interpreter.BroadcastEvent(
+CommandInterpreter::eBroadcastBitQuitCommandReceived);
+result.SetStatus(eReturnStatusQuit);
 return result.Succeeded();
   }
 };



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


[Lldb-commits] [PATCH] D69931: Add rpath to liblldb so vendors can ship their own python framework (or others)

2019-11-11 Thread Shoaib Meenai via Phabricator via lldb-commits
smeenai accepted this revision.
smeenai added a comment.

LGTM




Comment at: lldb/cmake/modules/LLDBFramework.cmake:125
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+# This allows frameworks (relying on @rpath) to be installed in the same 
folder and found at runtime.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH

Nit: 80 columns


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931



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


[Lldb-commits] [PATCH] D70100: [DWARF] Handle call sites with indirect call targets

2019-11-11 Thread Vedant Kumar via Phabricator via lldb-commits
vsk created this revision.
vsk added reviewers: aprantl, friss, jingham.

Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.

Writing tests for this is challenging, at the moment, because llvm emits
DW_AT_call_targets describing clobbered register values (llvm.org/PR43926).
I found a way to cover the non-tail call case, but would have to resort to
flaky assembly gadgets to test indirect tail-calls. I've left this for later.

rdar://57094085


https://reviews.llvm.org/D70100

Files:
  lldb/include/lldb/Symbol/Function.h
  lldb/include/lldb/Symbol/SymbolFile.h
  
lldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/main.cpp
  lldb/source/Expression/DWARFExpression.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  lldb/source/Symbol/Function.cpp
  lldb/source/Target/StackFrameList.cpp

Index: lldb/source/Target/StackFrameList.cpp
===
--- lldb/source/Target/StackFrameList.cpp
+++ lldb/source/Target/StackFrameList.cpp
@@ -243,7 +243,8 @@
 /// \p return_pc) to \p end. On success this path is stored into \p path, and 
 /// on failure \p path is unchanged.
 static void FindInterveningFrames(Function &begin, Function &end,
-  Target &target, addr_t return_pc,
+  ExecutionContext &exe_ctx, Target &target,
+  addr_t return_pc,
   std::vector &path,
   ModuleList &images, Log *log) {
   LLDB_LOG(log, "Finding frames between {0} and {1}, retn-pc={2:x}",
@@ -251,9 +252,9 @@
 
   // Find a non-tail calling edge with the correct return PC.
   if (log)
-for (const CallEdge &edge : begin.GetCallEdges())
+for (const auto &edge : begin.GetCallEdges())
   LLDB_LOG(log, "FindInterveningFrames: found call with retn-PC = {0:x}",
-   edge.GetReturnPCAddress(begin, target));
+   edge->GetReturnPCAddress(begin, target));
   CallEdge *first_edge = begin.GetCallEdgeForReturnAddress(return_pc, target);
   if (!first_edge) {
 LLDB_LOG(log, "No call edge outgoing from {0} with retn-PC == {1:x}",
@@ -262,7 +263,7 @@
   }
 
   // The first callee may not be resolved, or there may be nothing to fill in.
-  Function *first_callee = first_edge->GetCallee(images);
+  Function *first_callee = first_edge->GetCallee(images, exe_ctx);
   if (!first_callee) {
 LLDB_LOG(log, "Could not resolve callee");
 return;
@@ -283,8 +284,10 @@
 bool ambiguous = false;
 Function *end;
 ModuleList &images;
+ExecutionContext &context;
 
-DFS(Function *end, ModuleList &images) : end(end), images(images) {}
+DFS(Function *end, ModuleList &images, ExecutionContext &context)
+: end(end), images(images), context(context) {}
 
 void search(Function &first_callee, std::vector &path) {
   dfs(first_callee);
@@ -313,8 +316,8 @@
 
   // Search the calls made from this callee.
   active_path.push_back(&callee);
-  for (CallEdge &edge : callee.GetTailCallingEdges()) {
-Function *next_callee = edge.GetCallee(images);
+  for (const auto &edge : callee.GetTailCallingEdges()) {
+Function *next_callee = edge->GetCallee(images, context);
 if (!next_callee)
   continue;
 
@@ -326,7 +329,7 @@
 }
   };
 
-  DFS(&end, images).search(*first_callee, path);
+  DFS(&end, images, exe_ctx).search(*first_callee, path);
 }
 
 /// Given that \p next_frame will be appended to the frame list, synthesize
@@ -379,8 +382,10 @@
   addr_t return_pc = next_reg_ctx_sp->GetPC();
   Target &target = *target_sp.get();
   ModuleList &images = next_frame.CalculateTarget()->GetImages();
-  FindInterveningFrames(*next_func, *prev_func, target, return_pc, path, images,
-log);
+  ExecutionContext exe_ctx(target_sp, /*get_process=*/true);
+  exe_ctx.SetFramePtr(&next_frame);
+  FindInterveningFrames(*next_func, *prev_func, exe_ctx, target, return_pc,
+path, images, log);
 
   // Push synthetic tail call frames.
   for (Function *callee : llvm::reverse(path)) {
Index: lldb/source/Symbol/Function.cpp
===
--- lldb/source/Symbol/Function.cpp
+++ lldb/source/Symbol/Function.cpp
@@ -17,6 +17,7 @@
 #include "lldb/Symbol/LineTable.h"
 #include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Target/Language.h"
+#include "lldb/Target/Target.h"
 #include "lldb/Utility/Log.h"
 #include "llvm/Support/Casting.h"
 
@@ -127,23 +128,21 @@
   return FunctionInfo::MemorySize() + m_mangled.MemorySize();

[Lldb-commits] [PATCH] D70002: [lldb] Make Target* a Target& in CommandObjectExpression::DoExecute REPL logic

2019-11-11 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

I don't think either version is right.

We really shouldn't be using "GetSelectedTarget" (with or without the Dummy) 
for getting the Target context for a command.  That's how it was originally 
done, but you aren't guaranteed that the selected target is the right target 
context in callbacks that use commands.

For instance, if lldb has two targets running in one debugger, and Target A is 
the currently selected target, but target B hits a breakpoint and the 
breakpoint has commands, we need to make sure the commands run in the 
breakpoint use target B.  But we don't select Target B when we hit the 
breakpoint, since I want to keep that Selected Target more under the user's 
control.  Instead we set the appropriate target in the command's m_exe_ctx, and 
commands are supposed to pull it from there.  BTW, I see that there are still a 
bunch of commands that haven't been updated to use this.  Maybe we ought to 
have a "GetCurrentOrDummyTarget" in CommandObject that returns the target from 
m_exe_ctx, or the dummy target if that is empty.  Either that or put the Dummy 
target IN m_exe_ctx if there is no appropriate target, and have everybody use 
that.

Anyway, this isn't more wrong than the previous version, but it isn't right 
either...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70002



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


[Lldb-commits] [PATCH] D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance

2019-11-11 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik updated this revision to Diff 228774.
shafik added a comment.

- Adjust comment
- matching_lambda argument is now `FunctionSP` to match `ForeachFunction` 
signature.


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

https://reviews.llvm.org/D69913

Files:
  lldb/include/lldb/Symbol/CompileUnit.h
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
  
lldb/packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/TestStdFunctionStepIntoCallable.py
  
lldb/packages/Python/lldbsuite/test/lang/cpp/std-function-step-into-callable/main.cpp
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Symbol/CompileUnit.cpp

Index: lldb/source/Symbol/CompileUnit.cpp
===
--- lldb/source/Symbol/CompileUnit.cpp
+++ lldb/source/Symbol/CompileUnit.cpp
@@ -12,6 +12,7 @@
 #include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Symbol/VariableList.h"
 #include "lldb/Target/Language.h"
+#include "lldb/Utility/Timer.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -81,6 +82,31 @@
   return;
 }
 
+lldb::FunctionSP CompileUnit::FindFunction(
+llvm::function_ref matching_lambda) {
+  static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
+  Timer scoped_timer(func_cat, "CompileUnit::FindFunction");
+
+  lldb::ModuleSP module = CalculateSymbolContextModule();
+
+  if (!module)
+return {};
+
+  SymbolFile *symbol_file = module->GetSymbolFile();
+
+  if (!symbol_file)
+return {};
+
+  // m_functions_by_uid is filled in lazily but we need all the entries.
+  symbol_file->ParseFunctions(*this);
+
+  for (auto &p : m_functions_by_uid) {
+if (matching_lambda(p.second))
+  return p.second;
+  }
+  return {};
+}
+
 // Dump the current contents of this object. No functions that cause on demand
 // parsing of functions, globals, statics are called, so this is a good
 // function to call to get an idea of the current contents of the CompileUnit
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -828,6 +828,8 @@
 }
 
 size_t SymbolFileDWARF::ParseFunctions(CompileUnit &comp_unit) {
+  static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
+  Timer scoped_timer(func_cat, "SymbolFileDWARF::ParseFunctions");
   std::lock_guard guard(GetModuleMutex());
   DWARFUnit *dwarf_cu = GetDWARFCompileUnit(&comp_unit);
   if (!dwarf_cu)
Index: lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
===
--- lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -21,6 +21,7 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/UniqueCStringMap.h"
 #include "lldb/Symbol/ClangASTContext.h"
+#include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Target/ABI.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/RegisterContext.h"
@@ -28,6 +29,7 @@
 #include "lldb/Target/StackFrame.h"
 #include "lldb/Target/ThreadPlanRunToAddress.h"
 #include "lldb/Target/ThreadPlanStepInRange.h"
+#include "lldb/Utility/Timer.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -58,9 +60,53 @@
   return false;
 }
 
+bool contains_lambda_identifier(llvm::StringRef &str_ref) {
+  return str_ref.contains("$_") || str_ref.contains("'lambda'");
+};
+
+CPPLanguageRuntime::LibCppStdFunctionCallableInfo
+line_entry_helper(Target &target, const SymbolContext &sc, Symbol *symbol,
+  llvm::StringRef first_template_param_sref,
+  bool has___invoke) {
+
+  CPPLanguageRuntime::LibCppStdFunctionCallableInfo optional_info;
+
+  AddressRange range;
+  sc.GetAddressRange(eSymbolContextEverything, 0, false, range);
+
+  Address address = range.GetBaseAddress();
+
+  Address addr;
+  if (target.ResolveLoadAddress(address.GetCallableLoadAddress(&target),
+addr)) {
+LineEntry line_entry;
+addr.CalculateSymbolContextLineEntry(line_entry);
+
+if (contains_lambda_identifier(first_template_param_sref) || has___invoke) {
+  // Case 1 and 2
+  optional_info.callable_case = lldb_private::CPPLanguageRuntime::
+  LibCppStdFunctionCallableCase::Lambda;
+} else {
+  // Case 3
+  optional_info.callable_case = lldb_private::CPPLanguageRuntime::
+  LibCppStdFunctionCallableCase::CallableObject;
+}
+
+optional_info.callable_symbol = *symbol;
+optional_info.callable_line_entry = line_entry;
+optional_info.callable_address = addr;
+  }
+
+  retur

[Lldb-commits] [PATCH] D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance

2019-11-11 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik marked an inline comment as done.
shafik added a comment.

In D69913#1739579 , @jingham wrote:

> Why not have the FindFunctions lambda take a FunctionSP?  It would be easy to 
> get the Function name out of the function in the lambda, and that would make 
> the function more general (and also match what the Foreach does...


It was not obvious how they were using it at first, good catch.


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

https://reviews.llvm.org/D69913



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


[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

2019-11-11 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

So, if I understand correctly, this patch doesn't just add an "ABI" plugin (for 
which we have in the past agreed that we don't know of a better way to test 
than just running  "TestReturnValue" on the given architecture), but it 
actually adds all the bits and pieces necessary to support risc-v debugging, 
*sans* an actual debug server. This means that one cannot test this code, even 
if he happened to have risc-v hardware around. I'm not really sure what's our 
position on that, which is why it took me so long to write this comment, and 
why I am reluctant to hit accept (even though the code itself seems pretty 
good).

I take it you have some proprietary/downstream debug server/hardware probe that 
you're using this with? And you're not putting that stuff in lldb-server 
because lldb-server is too heavy for your use case ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62732



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


[Lldb-commits] [PATCH] D70100: [DWARF] Handle call sites with indirect call targets

2019-11-11 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment.

Mechanically, this seems reasonable.




Comment at: lldb/include/lldb/Symbol/Function.h:334
 
-  DISALLOW_COPY_AND_ASSIGN(CallEdge);
+/// An indirect call site.
+class IndirectCallEdge : public CallEdge {

You might want to briefly explain what the difference between direct and 
indirect is here.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3752
 
-// Extract DW_AT_call_origin (the call target's DIE).
-DWARFDIE call_origin = child.GetReferencedDIE(DW_AT_call_origin);
-if (!call_origin.IsValid()) {
-  LLDB_LOG(log, "CollectCallEdges: Invalid call origin in {0}",
-   function_die.GetPubname());
+llvm::Optional call_origin = {};
+llvm::Optional call_target = {};

the `= {}` is redundant with the default constructor of Optional.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3816
+} else {
+  StreamString call_target_desc;
+  call_target->GetDescription(&call_target_desc, eDescriptionLevelBrief,

Can we make it so that work is only done when logging is requested?


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

https://reviews.llvm.org/D70100



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


[Lldb-commits] [lldb] 0b8dfb5 - [lldb] Re-enable VSCode tests

2019-11-11 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2019-11-11T15:59:54-08:00
New Revision: 0b8dfb5762fdc350c5071c9eeffd4f7e4d495e98

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

LOG: [lldb] Re-enable VSCode tests

The VSCode tests were all disabled on macOS because the implementation
had some issues that resulted in flakiness on Darwin. It seems most of
these issues have been addressed. I've re-enabled all the tests that
consistently passed locally.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setExceptionBreakpoints.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setFunctionBreakpoints.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/launch/TestVSCode_launch.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/stackTrace/TestVSCode_stackTrace.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py

lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/variables/TestVSCode_variables.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
index 2cac88fa0d4c..7c219b95b598 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py
@@ -46,7 +46,6 @@ def set_and_hit_breakpoint(self, continueToExit=True):
 
 
 @skipIfWindows
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
 @skipIfNetBSD # Hangs on NetBSD as well
 @no_debug_info_test
 def test_by_pid(self):
@@ -63,7 +62,6 @@ def test_by_pid(self):
 self.set_and_hit_breakpoint(continueToExit=True)
 
 @skipIfWindows
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
 @skipIfNetBSD # Hangs on NetBSD as well
 @no_debug_info_test
 def test_by_name(self):
@@ -99,7 +97,7 @@ def cleanup():
 self.set_and_hit_breakpoint(continueToExit=True)
 
 @skipUnlessDarwin
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
+@skipIfDarwin
 @skipIfNetBSD # Hangs on NetBSD as well
 @no_debug_info_test
 def test_by_name_waitFor(self):
@@ -117,7 +115,7 @@ def test_by_name_waitFor(self):
 self.set_and_hit_breakpoint(continueToExit=True)
 
 @skipIfWindows
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
+@skipIfDarwin
 @skipIfNetBSD # Hangs on NetBSD as well
 @no_debug_info_test
 def test_commands(self):

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
index c674a7f5f993..a4a5a31b7077 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
@@ -18,7 +18,6 @@ class 
TestVSCode_setBreakpoints(lldbvscode_testcase.VSCodeTestCaseBase):
 mydir = TestBase.compute_mydir(__file__)
 
 @skipIfWindows
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
 @no_debug_info_test
 def test_set_and_clear(self):
 '''Tests setting and clearing source file and line breakpoints.
@@ -151,7 +150,6 @@ def test_set_and_clear(self):
 "expect breakpoint still verified")
 
 @skipIfWindows
-@skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
 @no_debug_info_test
 def test_functionality(self):
 '''Tests hitting breakpoints and the functionality of a single

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setExceptionBreakpoints.py
 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setExceptionBreakpoints.py
index a9338b1809bd..c70875306e70 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setExceptionBreakpoints.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/breakpoint/TestVSCode_setExceptionBreakpoints.py
@@ -18,7 +18,6 @@ class TestVSCode_setExceptionBreakpoints(
 mydir = Tes

[Lldb-commits] [PATCH] D70106: Performance: Add a set of visited SymbolFiles to other the FindFiles variant.

2019-11-11 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl created this revision.
aprantl added reviewers: JDevlieghere, jasonmolenda.
Herald added a reviewer: shafik.

This is basically the same bug as in r260434 again. SymbolFileDWARF::FindTypes 
has exponential worst-case when digging through dependency DAG of .pcms because 
each object file and pcm may depend on an already-visited .pcm, which may again 
have dependencies. Fixed here by carrying a set of already visited SymbolFiles 
around.

rdar://problem/56993424


https://reviews.llvm.org/D70106

Files:
  lldb/include/lldb/Core/Module.h
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/source/Core/Module.cpp
  lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
  lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
  lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
  lldb/source/Symbol/SymbolFile.cpp
  lldb/tools/lldb-test/lldb-test.cpp

Index: lldb/tools/lldb-test/lldb-test.cpp
===
--- lldb/tools/lldb-test/lldb-test.cpp
+++ lldb/tools/lldb-test/lldb-test.cpp
@@ -529,7 +529,7 @@
 Symfile.FindTypes(ConstString(Name), ContextPtr, UINT32_MAX, SearchedFiles,
   Map);
   else
-Module.FindTypes(parseCompilerContext(), languages, Map);
+Module.FindTypes(parseCompilerContext(), languages, SearchedFiles, Map);
 
   outs() << formatv("Found {0} types:\n", Map.GetSize());
   StreamString Stream;
Index: lldb/source/Symbol/SymbolFile.cpp
===
--- lldb/source/Symbol/SymbolFile.cpp
+++ lldb/source/Symbol/SymbolFile.cpp
@@ -134,7 +134,9 @@
 TypeMap &types) {}
 
 void SymbolFile::FindTypes(llvm::ArrayRef pattern,
-   LanguageSet languages, TypeMap &types) {}
+   LanguageSet languages,
+   llvm::DenseSet &searched_symbol_files,
+   TypeMap &types) {}
 
 void SymbolFile::AssertModuleLock() {
   // The code below is too expensive to leave enabled in release builds. It's
Index: lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -134,6 +134,7 @@
 
   void FindTypes(llvm::ArrayRef pattern,
  lldb_private::LanguageSet languages,
+ llvm::DenseSet &searched_symbol_files,
  lldb_private::TypeMap &types) override;
 
   void FindTypesByRegex(const lldb_private::RegularExpression ®ex,
Index: lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -1562,9 +1562,10 @@
   }
 }
 
-void SymbolFilePDB::FindTypes(llvm::ArrayRef pattern,
-  LanguageSet languages,
-  lldb_private::TypeMap &types) {}
+void SymbolFilePDB::FindTypes(
+llvm::ArrayRef pattern, LanguageSet languages,
+llvm::DenseSet &searched_symbol_files,
+lldb_private::TypeMap &types) {}
 
 void SymbolFilePDB::GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol &pdb_symbol,
  uint32_t type_mask,
Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
@@ -131,6 +131,7 @@
  TypeMap &types) override;
 
   void FindTypes(llvm::ArrayRef pattern, LanguageSet languages,
+ llvm::DenseSet &searched_symbol_files,
  TypeMap &types) override;
 
   llvm::Expected
Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1259,8 +1259,9 @@
   FindTypesByName(name.GetStringRef(), max_matches, types);
 }
 
-void SymbolFileNativePDB::FindTypes(llvm::ArrayRef pattern,
-LanguageSet languages, TypeMap &types) {}
+void SymbolFileNativePDB::FindTypes(
+llvm::ArrayRef pattern, LanguageSet languages,
+llvm::DenseSet &searched_symbol_files, TypeMap &types) {}
 
 void SymbolFileNativePDB::FindTypesByName(llvm::StringRef name,
   

[Lldb-commits] [PATCH] D69704: [lldb] Add IsTypeSystemCompatible method to SBModule to allow checking compatibility between language versions

2019-11-11 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

In D69704#1732484 , @labath wrote:

> The part that bothers me here is that this assumes that the entirety of a 
> module (or an least the portion of it written in the same language) uses the 
> same version of the language. Is that true for swift? Because it definitely 
> isn't true for c++, as you can easily mix compile units built with different 
> `-std` flags (and most of the time it will work). So it's not clear to me how 
> this would work for c/c++, or any other language that offers some kind of a 
> version-independent ABI, thus, enabling one to combine different versions in 
> a single module.  Nevertheless, since this is how swift works, it seems 
> reasonable to have some way to access this information. However, it's not 
> clear to me if this is the best way to do that...


This call is actually being used to tell whether the type system in a given 
module is compatible with LLDB, not with some other compile units in the same 
module or other modules in the program.  That is an issue for Swift because the 
type information for Swift is not stored in DWARF, but in the .swiftmodule 
file, which is a fancy dump of internal compiler state.  So for lldb to be able 
to debug a swift module, it has to have been built with exactly the same 
version of the swift compiler as was built into lldb, or things go very wrong.  
That also answers your question about swift: you have to build all the source 
inputs to a Swift module with the same version of the Swift compiler.  There is 
a version neutral text interface file, but that is only able to describe the 
public interface to a module.  It allows you to build code against extant 
modules from different versions of the Swift compiler.  But the information 
about private methods are only in the binary format, and so you still need the 
same version of swift to glom them all together.

If, for instance, we decided to use .pcm files as a serialization form for type 
info you would need the same sort of check for modules backed by these pcm's - 
since the clang in lldb and the clang building the pcm would have to match.  
BTW I am NOT suggesting that would be a good idea, and this will probably 
always be a no-op for anything but Swift.

> Another thing on my mind is the name (type system). AFAICT, this is the first 
> mention of these words in all of `lldb/API` headers, so one would get the 
> impression that type systems are an internal implementation detail of lldb. 
> That's why this methods sort of jumps out in your face. Are we planning to 
> make more type system-y stuff visible at the SB level? If not, could we make 
> this name more generic? Maybe, IsDebugInfoCompatible (with the meaning that 
> lldb is able to understand all of debug info (of a given language) in this 
> module)?

IsDebugInfoCompatible is a more explicit name.  It would be cool at some point 
to write a TypeSystem as a pure plugin, but we're nowhere near that.  So I 
agree it's better to reserve TypeSystem for lldb_private if we aren't really 
exposing it.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D69704



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


[Lldb-commits] [PATCH] D69931: Add rpath to liblldb so vendors can ship their own python framework (or others)

2019-11-11 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG31ea714e9a94: Add rpath to liblldb so vendors can ship their 
own python framework (or others) (authored by António Afonso 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69931

Files:
  lldb/cmake/modules/LLDBFramework.cmake


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,8 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+# This allows frameworks (relying on @rpath) to be installed in the same 
folder and found at runtime.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")


Index: lldb/cmake/modules/LLDBFramework.cmake
===
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -120,3 +120,8 @@
 COMMENT "LLDB.framework: copy clang vendor-specific headers"
   )
 endif()
+
+# Add an rpath pointing to the directory where LLDB.framework is installed.
+# This allows frameworks (relying on @rpath) to be installed in the same folder and found at runtime.
+set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH
+  "@loader_path/../../../")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits