The patch works for x86 remote debugging as well.
$ ../binaries/x86_debug/bin/lldb --version
lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
revision 312008)
clang revision 312008
llvm revision 312008
On Tue, Aug 29, 2017 at 10:51 PM, Ramana wrote:
> Thanks Chris. The patch
Hello testers,
5.0.0-rc4 was just tagged.
There were very few changes after rc3, and if nothing unexpected comes
up, this is what the final release will look like.
Please test and let me know if there are any issues.
Cheers,
Hans
___
lldb-dev mailing
Hi Tamas,
I was able to use your suggestion as follows:
diff --git a/source/Expression/CMakeLists.txt b/source/Expression/CMakeLists.txt
index 7d9643a..b53b095 100644
--- a/source/Expression/CMakeLists.txt
+++ b/source/Expression/CMakeLists.txt
@@ -2,6 +2,12 @@ if(NOT LLDB_BUILT_STANDALONE)
r310959 contains GNU extensions in source/Plugins/Language/ObjC/NSArray.cpp.
Building with clang 3.8 and -WError, I see:
/local/mnt/workspace/bots/llvmhexbot-sles11_sd_48/hexagon-clang-83/build/llv
m/tools/lldb/source/Plugins/Language/ObjC/NSArray.cpp:181:7: error:
anonymous structs are a GNU exte
I’ve pondered integrating the REPL into LLDB - but what I really want/need is
for all of this to run within SLIME - and I don’t know enough about it to do
that.
I do know how to talk to complex C++ API’s from Common Lisp - hence my line of
questioning.
I’ll think on that more though. What you
On Tue, 29 Aug 2017 21:05:32 +0200, meister via lldb-dev wrote:
> Common Lisp is a different kind of language - it’s never supposed to seg
> fault. :-)
>
> It’s a dynamic language that I am compiling to llvm-ir and using to call and
> drive C++ libraries.
> The integrated debugger takes over when
Common Lisp is a different kind of language - it’s never supposed to seg fault.
:-)
It’s a dynamic language that I am compiling to llvm-ir and using to call and
drive C++ libraries.
The integrated debugger takes over when an error is signaled and it should
allow the user to view the stack, insp
By the way: "swift" ends up executing:
/Applications/Xcode.app/Contents/Developer/usr/bin/lldb
--repl=-enable-objc-interop -sdk
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-color-diagnostics
> On Aug 29, 2017, at 12:03 PM, Greg Clayton
> On Aug 29, 2017, at 11:41 AM, meister wrote:
>
> Greg,
>
> We are developing a compiler for Common Lisp that uses LLVM as the backend
> and interoperates with C++ - it has its own REPL and built in compiler.
> Our compiler generates llvm-ir that we link directly with llvm-ir generated
>
lldb-mi, in /tools/lldb-mi , loads the shared library and uses the SB
APIs. That might be a good start for you. main() is in MIDriverMain.cpp.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Proje
On Tue, 29 Aug 2017 20:17:57 +0200, meister via lldb-dev wrote:
> (i) My program detects an error and enters into its debugger.
> (ii) It forks a debugging process and that interacts with the user who uses
> it to debug the main process.
> (iii) The debugger process shuts down and the main process
Greg,
We are developing a compiler for Common Lisp that uses LLVM as the backend and
interoperates with C++ - it has its own REPL and built in compiler.
Our compiler generates llvm-ir that we link directly with llvm-ir generated
from the C++ code using LTO.
I’ve exposed much of the LLVM C++ A
> On Aug 29, 2017, at 11:17 AM, meister wrote:
>
> Dear Greg,
>
> Thank you very much for your detailed and thoughtful response.
>
> A couple of followup questions based on what you said:
>
> (1) You say: "since LLDB can't be used to backtrace itself…"
> Do I (a) need to fork another process
Dear Greg,
Thank you very much for your detailed and thoughtful response.
A couple of followup questions based on what you said:
(1) You say: "since LLDB can't be used to backtrace itself…"
Do I (a) need to fork another process and call the LLDB API’s to get backtraces
for the original process
Thanks Chris. The patch woks for ARM remote debugging for my case. I
am yet to check x86 remote debugging. Need to build the tool chain, so
will update you tomorrow.
~# /mnt/var/arm_debug/bin/lldb --version
lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
revision 312008)
clang r
> On Aug 29, 2017, at 8:21 AM, meister via lldb-dev
> wrote:
>
> Does anyone have pointers on how to link the lldb C++ API/library with
> another project that uses a command line driven build system?
You can always use "xcodebuild" if you need to for Mac builds:
lldb:
cd /tmp/lldb
xc
I committed a fix in r312008. Please test it to verify that it resolves your
issue.
Thanks,
-Chris
> On Aug 28, 2017, at 8:41 PM, Ramana wrote:
>
> Thank you, Chris. Looking forward to the patch.
>
> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman wrote:
>> I had a chance to look into this m
https://bugs.llvm.org/show_bug.cgi?id=34183
Chris Bieneman changed:
What|Removed |Added
CC||chris.biene...@me.com
Status|NEW
Does anyone have pointers on how to link the lldb C++ API/library with another
project that uses a command line driven build system?
We would like to incorporate the lldb C++ API/library into our Common Lisp
programming environment to get better backtraces and debug info in a portable
way (OS X
Hi All,
We are trying to keep the size of lldb-server as small as possible as it
have to be copied over to the android device for every debug session. The
way we currently achieve this is by using linker garbage collection to get
rid of the unused code.
In the log term it would be nice to be more
20 matches
Mail list logo
