Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

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 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 revision 312008
>   llvm revision 312008
>
> "gdb-remote process" log of lldb-server says
>
>GDBRemoteCommunication::StartDebugserverProcess() debugserver
> listens 55874 port
>
> ~/Ramana# ps af -w
>   PID TTY  STAT   TIME COMMAND
>  8314 pts/0S+ 0:00  \_ /mnt/var/arm_debug/bin/lldb-server p
> --log-file Ramana/remote.log --log-channels gdb-remote process
> --server --listen *:1400
>  8421 pts/0Sl+0:01  \_ /mnt/var/arm_debug/bin/lldb-server
> p --log-file Ramana/remote.log --log-channels gdb-remote process
> --server --listen *:1400
>  8477 pts/0S+ 0:00  \_
> /mnt/var/arm_debug/bin/lldb-server gdbserver tcp://10.10.12.3:0
> --native-regs --pipe 7
>  8514 pts/0t  0:00  \_ /home/root/arm_main
>
>
>
> ~/work_root/ToT_lldb/tests$ ../binaries/x86_debug/bin/lldb
> (lldb) platform select remote-linux
>   Platform: remote-linux
>  Connected: no
> (lldb) platform connect connect://10.10.2.1:1400
>   Platform: remote-linux
> Triple: arm-*-linux-gnueabihf
> OS Version: 4.1.33 (4.1.33-ltsi-altera)
> Kernel: #1 SMP Tue May 2 08:13:11 MYT 2017
>   Hostname: arria5
>  Connected: yes
> WorkingDir: /home/root
> (lldb) file arm_main
> Current executable set to 'arm_main' (arm).
> (lldb) b main
> Breakpoint 1: where = arm_main`main + 4 at main.c:4, address = 0x000104a0
> (lldb) run
> Process 8514 launched: '/home/ramanan/work_root/ToT_lldb/tests/arm_main' (arm)
> Process 8514 stopped
> * thread #1, name = 'arm_main', stop reason = breakpoint 1.1
> frame #0: 0x000104a0 arm_main`main at main.c:4
>1#include 
>2
>3int main() {
> -> 4printf("Hello World\n");
>5}
> (lldb) n
> Hello World
> Process 8514 stopped
> * thread #1, name = 'arm_main', stop reason = step over
> frame #0: 0x000104ae arm_main`main at main.c:5
>2
>3int main() {
>4printf("Hello World\n");
> -> 5}
>
>
>
> Regards,
> Ramana
>
> On Tue, Aug 29, 2017 at 9:49 PM, Chris Bieneman  wrote:
>> 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 more, and I found a bug in the listen 
 behavior. I'm testing a solution to it now. Will post it if it resolves 
 the issue.

 -Chris

> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>  wrote:
>
> Maybe we can make it open only an IPv4 socket for lldb-server for now as 
> a work around?
>
>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>>
>> Since lldb-server only supports running on a limited set of host 
>> operating systems it is hard for me to diagnose the issue completely, 
>> but I suspect the problem is caused by the fact that the new listening 
>> code can open more than one socket, and TCPSocket::GetLocalPortNumber() 
>> may be misbehaving.
>>
>> I'm unlikely to have time to investigate further until next week, but it 
>> should be possible to craft a unit test that verifies that 
>> GetLocalPortNumber() returns non-zero on a socket that is listening 
>> before a connection is established. That might reproduce the issue in a 
>> more easy to debug environment.
>>
>> -Chris
>>
>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev 
>>>  wrote:
>>>
>>> Ted, Greg,
>>>
>>> I have built lldb tools @r300578 and the lldb-server is returning the
>>> proper port number to lldb client and the remote debugging is working.
>>> I have given the lldb-server log at the bottom of my reply.
>>>
>>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>>> support IPv6 over TCP) is causing the issue.
>>>
 Ramana, can you stick in a log message to print port_cstr? I suspect 
 it's actually getting 0 back from lldb-server, which would tell us the 
 error is in the server code, not the client code.
>>>
>>> Ted, I did that and actually the pipe read is returning zero port

[lldb-dev] [5.0.0 Release] Release Candidate 4 tagged

[Hans Wennborg via lldb-dev]

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 list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-server link failure with shared library configuration

[Peeter Joot via lldb-dev]

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)

   set(tablegen_deps intrinsics_gen)

 endif()

+set(LLDB_EXP_DEPS)

+

+if(BUILD_SHARED_LIBS)

+  list(APPEND LLDB_EXP_DEPS LLVMRuntimeDyld)

+endif()

+

 add_lldb_library(lldbExpression

   DiagnosticManager.cpp

   DWARFExpression.cpp

@@ -30,6 +36,7 @@ add_lldb_library(lldbExpression

 lldbTarget

 lldbUtility

 lldbPluginExpressionParserClang

+${LLDB_EXP_DEPS}

   LINK_COMPONENTS

 Core

and was able to successfully build the lldb-server.

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

[lldb-dev] warnings in source/Plugins/Language/ObjC/NSArray.cpp

[Ted Woodward via lldb-dev]

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 extension [-Werror,-Wgnu-anonymous-struct]
  struct {
  ^
/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 types declared in an anonymous union are an extension
[-Werror,-Wnested-anon-types]


The patch is to handle new MacOS 10.13 internal layouts. Could someone at
Apple please clean this up?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[meister via lldb-dev]

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 describe might be appropriate for an 
interactive development mode.   Thank you.

Common Lisp users have certain expectations that they will get backtraces with 
arguments and be able to interactively inspect arguments and lexical variables 
using the interactive SLIME Debugger interface in Emacs.  The more I use that 
interface - the more I fall in love with it.
I’m trying to figure out where the best compromise is.

Best,

.Chris.

> On Aug 29, 2017, at 3:03 PM, Greg Clayton  wrote:
> 
> 
>> 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 
>> from the C++ code using LTO.
>> I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for 
>> automatic analysis and refactoring of our C++ code.
>> 
>> The Python API’s are not that useful to us.   
>> Although - maybe launching lldb as a separate process to get the backtrace 
>> with a python script may be a reasonable thing to do - if that’s all that I 
>> want to do.
>> I’d also like to explore accessing lexical variables and setting breakpoints 
>> and watchpoints using the C++ API.
>> The C++ API’s - they are much more straightforward to work with for us.
>> 
>> I am already using ‘backtrace’ - but I don’t get function arguments with 
>> that sadly.
> 
> You might think about integrating your REPL directly into LLDB? That is how 
> we did it with Swift. Then you get everything for free:
> - debug your REPL code by setting breakpoints
> - when a REPL code snippet crashes, see the backtrace!
> 
> You might search for a Swift REPL demo and see what you think. 
> 
> 
> Below is an example of the Swift REPL that is built into LLDB:
> 
> $ swift
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42). Type 
> :help for assistance.
>  1> func foo() -> Int {
>  2. return 12; 
>  3. } 
>  4. 
>  4> foo()
> $R0: Int = 12
> 
> 
> Any line that starts with ':' is a LLDB command. Below we set a breakpoint on 
> line 2 of our REPL code:
> 
>  5> :b 2
> Breakpoint 1: where = $__lldb_expr3`__lldb_expr_2.foo () -> Swift.Int + 4 at 
> repl.swift:2, address = 0x0001000c5014
> 
> Now we can call foo() and hit our breakpoint:
> 
> 
>  5> foo()
> Execution stopped at breakpoint.  Enter LLDB commands to investigate (type 
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
>   1   func foo() -> Int {
> -> 2  return 12;
>   3   }
>   4   foo()
>   5   foo()
> 
> 
> Note we drop into the LLDB command prompt. We can view variables, backtrace, 
> etc. Here we just continue:
> 
> (lldb) c
> Process 40238 resuming
> 
> Now we are back in the REPL:
> 
>  6> func bar() -> Int { 
>  7. return foo() + 23; 
>  8. } 
>  9> bar()
> 
> We are going to call "bar()" which will call "foo()" so we will hit the 
> breakpoint again...
> 
> 
> Execution stopped at breakpoint.  Enter LLDB commands to investigate (type 
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
>   1   func foo() -> Int {
> -> 2  return 12;
>   3   }
>   4   foo()
>   5   foo()
>   6   func bar() -> Int {
>   7   return foo() + 23;
> (lldb) c
> Process 40238 resuming
> 10>  
> 
> 
> 
> 

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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Jan Kratochvil via lldb-dev]

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 an error is signaled

So "error is signaled" is like an assert()?  assert() generates SIGABRT so
that system crash reporter will catch it, backtrace it, bugreport it etc.

Or a debugger will catch it the same way if developer has run it.


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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[meister via lldb-dev]

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, inspect arguments and lexical variables and 
to unwind the stack and proceed indefinitely.

Now, I’m generating llvm-ir and that runs just like C++ generated llvm-ir.  
My stack traces are C++ style stack traces with stack frames from C++ functions 
interleaved with stack frames from Common Lisp code.
I use C++ exception handling to unwind the stack in Common Lisp and that 
enables RAII to keep working.

I’m kind of caught between worlds.  I already have a debugger that can view 
stack traces - but to achieve it I’ve had to insert calls at the entry and exit 
of all Common Lisp functions to spill register arguments and to maintain a 
shadow stack of stack frames for Common Lisp functions.  This is a huge barrier 
to inlining and optimization.  I also generate DWARF metadata but I can’t 
access it without going through lldb.
That’s why I’d like to incorporate the lldb C++ API’s.

Best,

.Chris.



> On Aug 29, 2017, at 2:48 PM, Jan Kratochvil  wrote:
> 
> 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 continues.
> 
> For catching runtime errors on Linux you should just SEGV and system crash
> reporter will catch it, backtrace it, bugreport it etc.  At least ABRT in
> Fedora/RHEL case, other distros have some similar tools for that.
> 
> And developers should run the program under debugger in the first place.
> 
> 
> Jan

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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Greg Clayton via lldb-dev]

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  wrote:
> 
> 
>> 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 
>> from the C++ code using LTO.
>> I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for 
>> automatic analysis and refactoring of our C++ code.
>> 
>> The Python API’s are not that useful to us.   
>> Although - maybe launching lldb as a separate process to get the backtrace 
>> with a python script may be a reasonable thing to do - if that’s all that I 
>> want to do.
>> I’d also like to explore accessing lexical variables and setting breakpoints 
>> and watchpoints using the C++ API.
>> The C++ API’s - they are much more straightforward to work with for us.
>> 
>> I am already using ‘backtrace’ - but I don’t get function arguments with 
>> that sadly.
> 
> You might think about integrating your REPL directly into LLDB? That is how 
> we did it with Swift. Then you get everything for free:
> - debug your REPL code by setting breakpoints
> - when a REPL code snippet crashes, see the backtrace!
> 
> You might search for a Swift REPL demo and see what you think. 
> 
> 
> Below is an example of the Swift REPL that is built into LLDB:
> 
> $ swift
> Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42). Type 
> :help for assistance.
>  1> func foo() -> Int {
>  2. return 12; 
>  3. } 
>  4. 
>  4> foo()
> $R0: Int = 12
> 
> 
> Any line that starts with ':' is a LLDB command. Below we set a breakpoint on 
> line 2 of our REPL code:
> 
>  5> :b 2
> Breakpoint 1: where = $__lldb_expr3`__lldb_expr_2.foo () -> Swift.Int + 4 at 
> repl.swift:2, address = 0x0001000c5014
> 
> Now we can call foo() and hit our breakpoint:
> 
> 
>  5> foo()
> Execution stopped at breakpoint.  Enter LLDB commands to investigate (type 
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
>   1   func foo() -> Int {
> -> 2  return 12;
>   3   }
>   4   foo()
>   5   foo()
> 
> 
> Note we drop into the LLDB command prompt. We can view variables, backtrace, 
> etc. Here we just continue:
> 
> (lldb) c
> Process 40238 resuming
> 
> Now we are back in the REPL:
> 
>  6> func bar() -> Int { 
>  7. return foo() + 23; 
>  8. } 
>  9> bar()
> 
> We are going to call "bar()" which will call "foo()" so we will hit the 
> breakpoint again...
> 
> 
> Execution stopped at breakpoint.  Enter LLDB commands to investigate (type 
> help for assistance.)
> Process 40238 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
>   1   func foo() -> Int {
> -> 2  return 12;
>   3   }
>   4   foo()
>   5   foo()
>   6   func bar() -> Int {
>   7   return foo() + 23;
> (lldb) c
> Process 40238 resuming
> 10>  
> 
> 
> 
> 

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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Greg Clayton via lldb-dev]

> 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 
> from the C++ code using LTO.
> I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for 
> automatic analysis and refactoring of our C++ code.
> 
> The Python API’s are not that useful to us.   
> Although - maybe launching lldb as a separate process to get the backtrace 
> with a python script may be a reasonable thing to do - if that’s all that I 
> want to do.
> I’d also like to explore accessing lexical variables and setting breakpoints 
> and watchpoints using the C++ API.
> The C++ API’s - they are much more straightforward to work with for us.
> 
> I am already using ‘backtrace’ - but I don’t get function arguments with that 
> sadly.

You might think about integrating your REPL directly into LLDB? That is how we 
did it with Swift. Then you get everything for free:
- debug your REPL code by setting breakpoints
- when a REPL code snippet crashes, see the backtrace!

You might search for a Swift REPL demo and see what you think. 


Below is an example of the Swift REPL that is built into LLDB:

 $ swift
Welcome to Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42). Type 
:help for assistance.
  1> func foo() -> Int {
  2. return 12; 
  3. } 
  4. 
  4> foo()
$R0: Int = 12


Any line that starts with ':' is a LLDB command. Below we set a breakpoint on 
line 2 of our REPL code:

  5> :b 2
Breakpoint 1: where = $__lldb_expr3`__lldb_expr_2.foo () -> Swift.Int + 4 at 
repl.swift:2, address = 0x0001000c5014

Now we can call foo() and hit our breakpoint:


  5> foo()
Execution stopped at breakpoint.  Enter LLDB commands to investigate (type help 
for assistance.)
Process 40238 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
   1func foo() -> Int {
-> 2return 12;
   3}
   4foo()
   5foo()


Note we drop into the LLDB command prompt. We can view variables, backtrace, 
etc. Here we just continue:

(lldb) c
Process 40238 resuming

Now we are back in the REPL:

  6> func bar() -> Int { 
  7. return foo() + 23; 
  8. } 
  9> bar()

We are going to call "bar()" which will call "foo()" so we will hit the 
breakpoint again...


Execution stopped at breakpoint.  Enter LLDB commands to investigate (type help 
for assistance.)
Process 40238 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0001000c5014 $__lldb_expr3`foo() -> Int at repl.swift:2
   1func foo() -> Int {
-> 2return 12;
   3}
   4foo()
   5foo()
   6func bar() -> Int {
   7return foo() + 23;
(lldb) c
Process 40238 resuming
 10>  




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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Ted Woodward via lldb-dev]

 

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 Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of meister 
via lldb-dev
Sent: Tuesday, August 29, 2017 1:41 PM
To: clayb...@gmail.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linking the lldb C++API/library with other projects

 

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++ API and Clang ASTMatcher C++ API for 
automatic analysis and refactoring of our C++ code.

 

The Python API’s are not that useful to us.   

Although - maybe launching lldb as a separate process to get the backtrace with 
a python script may be a reasonable thing to do - if that’s all that I want to 
do.

I’d also like to explore accessing lexical variables and setting breakpoints 
and watchpoints using the C++ API.

The C++ API’s - they are much more straightforward to work with for us.

 

I am already using ‘backtrace’ - but I don’t get function arguments with that 
sadly.

 

Best,

 

.Chris.

 

 

 

 

On Aug 29, 2017, at 2:30 PM, Greg Clayton  > wrote:

 

 

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 and call the LLDB API’s to get backtraces 
for the original process or (b) can I simply create another thread and call 
LLDB API’s to interogate other threads using the SBThread API?  Or can I do 
both of these?

 

You can do the first, not the second. LLDB attaches to processes via ptrace 
which means it will suspend all threads in the process it is attaching to, so 
you can't do this to yourself. Forking another process will do the trick. You 
can also do all of this from Python! The entire LLDB API is exposed to python 
and python can be used on the command line from a python script, or from within 
LLDB itself by using the "script" command which drops you into an embedded 
python interpreter.  On Mac, if you know Xcode is installed, you can just run a 
python script to do what you need. Let me know if this sounds interesting. On 
linux, you could use the installed lldb to do the backtraces using a python 
script as well.






(2) When you say "so if you are looking to backtrace things in your current 
process you should probably use other APIs.”
By "other APIs” do you mean other SB class API’s like SBThread? or do you 
mean other API’s entirely? If the latter could you give an example?

 

Other APIs not in LLDB if you must stay in process:

 

$ man backtrace

 

If you launch another process, it will be able to backtrace your current 
process and you can use LLDB's APIs.

 


(3) If I call LLDB from my code like this - how would you recommend 
distributing this?

(a) When building from source should I have the build system pull lldb from a 
the llvm github repo?

 

You might think about locking onto they latest public release of lldb. This 
might be more stable than just grabbing top of tree.





(b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary 
release?

 

Yes. You might think about using python and just using the installed LLDB? 





(c) On OS X - can I use the builtin lldb library? I haven’t checked if header 
files are available.

 

Header files are not available, but our API is stable. You could theoretically 
link against the top of tree LLDB.framework and tell it to use the system 
version (in /Applications/Xcode.app/Contents/SharedFrameworks, or somewhere for 
linux)





(d) On Linux - can I use package manager installed versions of lldb? 

 

Yes. If you go this route, I would suggest using a python script. Then you 
don't even need to link against lldb! 






For some of these I realize that I'll have to do some legwork to figure out 
what is available from package managers etc.

(4) Since I have to debug from a separate process does the following sound 
reasonable.
(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 continues.

I’d be doing this from within a Common Lisp programming environment called 
SLIME in Emacs - I have no idea right now if it’s possible to have the 

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Jan Kratochvil via lldb-dev]

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 continues.

For catching runtime errors on Linux you should just SEGV and system crash
reporter will catch it, backtrace it, bugreport it etc.  At least ABRT in
Fedora/RHEL case, other distros have some similar tools for that.

And developers should run the program under debugger in the first place.


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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[meister via lldb-dev]

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++ API and Clang ASTMatcher C++ API for 
automatic analysis and refactoring of our C++ code.

The Python API’s are not that useful to us.   
Although - maybe launching lldb as a separate process to get the backtrace with 
a python script may be a reasonable thing to do - if that’s all that I want to 
do.
I’d also like to explore accessing lexical variables and setting breakpoints 
and watchpoints using the C++ API.
The C++ API’s - they are much more straightforward to work with for us.

I am already using ‘backtrace’ - but I don’t get function arguments with that 
sadly.

Best,

.Chris.




> On Aug 29, 2017, at 2:30 PM, Greg Clayton  wrote:
> 
> 
>> 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 and call the LLDB API’s to get 
>> backtraces for the original process or (b) can I simply create another 
>> thread and call LLDB API’s to interogate other threads using the SBThread 
>> API?  Or can I do both of these?
> 
> You can do the first, not the second. LLDB attaches to processes via ptrace 
> which means it will suspend all threads in the process it is attaching to, so 
> you can't do this to yourself. Forking another process will do the trick. You 
> can also do all of this from Python! The entire LLDB API is exposed to python 
> and python can be used on the command line from a python script, or from 
> within LLDB itself by using the "script" command which drops you into an 
> embedded python interpreter.  On Mac, if you know Xcode is installed, you can 
> just run a python script to do what you need. Let me know if this sounds 
> interesting. On linux, you could use the installed lldb to do the backtraces 
> using a python script as well.
> 
>> 
>> (2) When you say "so if you are looking to backtrace things in your current 
>> process you should probably use other APIs.”
>> By "other APIs” do you mean other SB class API’s like SBThread? or do 
>> you mean other API’s entirely? If the latter could you give an example?
> 
> Other APIs not in LLDB if you must stay in process:
> 
> $ man backtrace
> 
> If you launch another process, it will be able to backtrace your current 
> process and you can use LLDB's APIs.
> 
>> 
>> (3) If I call LLDB from my code like this - how would you recommend 
>> distributing this?
>> 
>> (a) When building from source should I have the build system pull lldb from 
>> a the llvm github repo?
> 
> You might think about locking onto they latest public release of lldb. This 
> might be more stable than just grabbing top of tree.
> 
>> (b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my 
>> binary release?
> 
> Yes. You might think about using python and just using the installed LLDB? 
> 
>> (c) On OS X - can I use the builtin lldb library? I haven’t checked if 
>> header files are available.
> 
> Header files are not available, but our API is stable. You could 
> theoretically link against the top of tree LLDB.framework and tell it to use 
> the system version (in /Applications/Xcode.app/Contents/SharedFrameworks, or 
> somewhere for linux)
> 
>> (d) On Linux - can I use package manager installed versions of lldb? 
> 
> Yes. If you go this route, I would suggest using a python script. Then you 
> don't even need to link against lldb! 
> 
>> 
>> For some of these I realize that I'll have to do some legwork to figure out 
>> what is available from package managers etc.
>> 
>> (4) Since I have to debug from a separate process does the following sound 
>> reasonable.
>> (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 continues.
>> 
>> I’d be doing this from within a Common Lisp programming environment called 
>> SLIME in Emacs - I have no idea right now if it’s possible to have the 
>> integrated debugger in SLIME work with a separate debugging process. Fun, 
>> fun, fun.
> 
> That sounds like it can work. If you want to actually use the debugger when 
> there is an issue, you will not want to use python. But if you are just 
> trying to get backtraces, then a  python script might work, plus it will 
> insulate you from having to link against lldb.
> 
>> Thank you!
> 
> No worries, we are here to help!
> 
> Let me know what you think about my 

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Greg Clayton via lldb-dev]

> 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 and call the LLDB API’s to get 
> backtraces for the original process or (b) can I simply create another thread 
> and call LLDB API’s to interogate other threads using the SBThread API?  Or 
> can I do both of these?

You can do the first, not the second. LLDB attaches to processes via ptrace 
which means it will suspend all threads in the process it is attaching to, so 
you can't do this to yourself. Forking another process will do the trick. You 
can also do all of this from Python! The entire LLDB API is exposed to python 
and python can be used on the command line from a python script, or from within 
LLDB itself by using the "script" command which drops you into an embedded 
python interpreter.  On Mac, if you know Xcode is installed, you can just run a 
python script to do what you need. Let me know if this sounds interesting. On 
linux, you could use the installed lldb to do the backtraces using a python 
script as well.

> 
> (2) When you say "so if you are looking to backtrace things in your current 
> process you should probably use other APIs.”
> By "other APIs” do you mean other SB class API’s like SBThread? or do you 
> mean other API’s entirely? If the latter could you give an example?

Other APIs not in LLDB if you must stay in process:

$ man backtrace

If you launch another process, it will be able to backtrace your current 
process and you can use LLDB's APIs.

> 
> (3) If I call LLDB from my code like this - how would you recommend 
> distributing this?
> 
> (a) When building from source should I have the build system pull lldb from a 
> the llvm github repo?

You might think about locking onto they latest public release of lldb. This 
might be more stable than just grabbing top of tree.

> (b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my 
> binary release?

Yes. You might think about using python and just using the installed LLDB? 

> (c) On OS X - can I use the builtin lldb library? I haven’t checked if header 
> files are available.

Header files are not available, but our API is stable. You could theoretically 
link against the top of tree LLDB.framework and tell it to use the system 
version (in /Applications/Xcode.app/Contents/SharedFrameworks, or somewhere for 
linux)

> (d) On Linux - can I use package manager installed versions of lldb? 

Yes. If you go this route, I would suggest using a python script. Then you 
don't even need to link against lldb! 

> 
> For some of these I realize that I'll have to do some legwork to figure out 
> what is available from package managers etc.
> 
> (4) Since I have to debug from a separate process does the following sound 
> reasonable.
> (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 continues.
> 
> I’d be doing this from within a Common Lisp programming environment called 
> SLIME in Emacs - I have no idea right now if it’s possible to have the 
> integrated debugger in SLIME work with a separate debugging process. Fun, 
> fun, fun.

That sounds like it can work. If you want to actually use the debugger when 
there is an issue, you will not want to use python. But if you are just trying 
to get backtraces, then a  python script might work, plus it will insulate you 
from having to link against lldb.

> Thank you!

No worries, we are here to help!

Let me know what you think about my above comments,

Greg Clayton


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

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[meister via lldb-dev]

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 or (b) can I simply create another thread and call 
LLDB API’s to interogate other threads using the SBThread API?  Or can I do 
both of these?

(2) When you say "so if you are looking to backtrace things in your current 
process you should probably use other APIs.”
By "other APIs” do you mean other SB class API’s like SBThread? or do you 
mean other API’s entirely? If the latter could you give an example?

(3) If I call LLDB from my code like this - how would you recommend 
distributing this?

(a) When building from source should I have the build system pull lldb from a 
the llvm github repo?
(b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary 
release?
(c) On OS X - can I use the builtin lldb library? I haven’t checked if header 
files are available.
(d) On Linux - can I use package manager installed versions of lldb? 

For some of these I realize that I'll have to do some legwork to figure out 
what is available from package managers etc.

(4) Since I have to debug from a separate process does the following sound 
reasonable.
(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 continues.

I’d be doing this from within a Common Lisp programming environment called 
SLIME in Emacs - I have no idea right now if it’s possible to have the 
integrated debugger in SLIME work with a separate debugging process. Fun, fun, 
fun.

Thank you!

.Chris.




> On Aug 29, 2017, at 1:18 PM, Greg Clayton  wrote:
> 
> 
>> 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
>xcodebuild -configuration Release
> 
> For all others cmake + ninja is the preferred method. Mac builds don't use 
> cmake + Ninja as we let Xcode make the LLDB.framework. A framework is a 
> directory that contains both the shared library and all public header files 
> needed in order for people to link against the LLDB shared library. It is 
> possible to build LLDB using cmake + ninja on Mac, but you end up with a 
> lldb.dylib shared library instead of a LLDB.framework. The nice thing about 
> the LLDB.framework being a directory is that it gives us a place to put all 
> of the support binaries that go along with LLDB: lldb-server, darwin-debug 
> (mac only), lldb-argdumper, header files needed by clang for expression 
> parsing, python modules, and more.
> 
> You can see all that is in the framework by doing:
> 
> $ find /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework -type 
> f
> [text deleted]

> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/Info.plist
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/MacOS/RootDebuggingXPCService
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc/Contents/version.plist
> 
> 
>> 
>> 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 and Linux).
>> 
>> lldb is written as a library and in principle this should be possible.   
>> In practice I’ve had a tough time getting started.  I can build lldb with 
>> Xcode on OS X.
>> This is not a criticism - I know resources are limited.  The documentation 
>> for using the C++ API of lldb are thin and examples are few to non-existent.
>> I don’t need a lot of help - I would just like a starting point.
> 
> To start with I would recommend:
> 1 - build with Xcode on Mac and link against the LLDB.framework
> 2 - build with cmake + ninja on all other systems and link against the 
> liblldb.so. Then you will need to package lldb, liblldb.so and all needed 
> extra files (lldb-* from the build directory, the python modules, etc) in a 
> place that LLDB can find them (usually all executables in the same directory, 
> python module in the same directory as liblldb.so (please correct me if I am 
> wrong on this linux folks!)
> 
> 
>> I’m developing CANDO, an implementation of Common Lisp that uses llvm as a 
>> backend  (github.com/drmeister/cando)
>> I have extensive experience using the llvm/clang API’s within CANDO.
> 
> That is good, 

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

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 revision 312008
  llvm revision 312008

"gdb-remote process" log of lldb-server says

   GDBRemoteCommunication::StartDebugserverProcess() debugserver
listens 55874 port

~/Ramana# ps af -w
  PID TTY  STAT   TIME COMMAND
 8314 pts/0S+ 0:00  \_ /mnt/var/arm_debug/bin/lldb-server p
--log-file Ramana/remote.log --log-channels gdb-remote process
--server --listen *:1400
 8421 pts/0Sl+0:01  \_ /mnt/var/arm_debug/bin/lldb-server
p --log-file Ramana/remote.log --log-channels gdb-remote process
--server --listen *:1400
 8477 pts/0S+ 0:00  \_
/mnt/var/arm_debug/bin/lldb-server gdbserver tcp://10.10.12.3:0
--native-regs --pipe 7
 8514 pts/0t  0:00  \_ /home/root/arm_main



~/work_root/ToT_lldb/tests$ ../binaries/x86_debug/bin/lldb
(lldb) platform select remote-linux
  Platform: remote-linux
 Connected: no
(lldb) platform connect connect://10.10.2.1:1400
  Platform: remote-linux
Triple: arm-*-linux-gnueabihf
OS Version: 4.1.33 (4.1.33-ltsi-altera)
Kernel: #1 SMP Tue May 2 08:13:11 MYT 2017
  Hostname: arria5
 Connected: yes
WorkingDir: /home/root
(lldb) file arm_main
Current executable set to 'arm_main' (arm).
(lldb) b main
Breakpoint 1: where = arm_main`main + 4 at main.c:4, address = 0x000104a0
(lldb) run
Process 8514 launched: '/home/ramanan/work_root/ToT_lldb/tests/arm_main' (arm)
Process 8514 stopped
* thread #1, name = 'arm_main', stop reason = breakpoint 1.1
frame #0: 0x000104a0 arm_main`main at main.c:4
   1#include 
   2
   3int main() {
-> 4printf("Hello World\n");
   5}
(lldb) n
Hello World
Process 8514 stopped
* thread #1, name = 'arm_main', stop reason = step over
frame #0: 0x000104ae arm_main`main at main.c:5
   2
   3int main() {
   4printf("Hello World\n");
-> 5}



Regards,
Ramana

On Tue, Aug 29, 2017 at 9:49 PM, Chris Bieneman  wrote:
> 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 more, and I found a bug in the listen 
>>> behavior. I'm testing a solution to it now. Will post it if it resolves the 
>>> issue.
>>>
>>> -Chris
>>>
 On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
  wrote:

 Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
 work around?

> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>
> Since lldb-server only supports running on a limited set of host 
> operating systems it is hard for me to diagnose the issue completely, but 
> I suspect the problem is caused by the fact that the new listening code 
> can open more than one socket, and TCPSocket::GetLocalPortNumber() may be 
> misbehaving.
>
> I'm unlikely to have time to investigate further until next week, but it 
> should be possible to craft a unit test that verifies that 
> GetLocalPortNumber() returns non-zero on a socket that is listening 
> before a connection is established. That might reproduce the issue in a 
> more easy to debug environment.
>
> -Chris
>
>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev 
>>  wrote:
>>
>> Ted, Greg,
>>
>> I have built lldb tools @r300578 and the lldb-server is returning the
>> proper port number to lldb client and the remote debugging is working.
>> I have given the lldb-server log at the bottom of my reply.
>>
>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>> support IPv6 over TCP) is causing the issue.
>>
>>> Ramana, can you stick in a log message to print port_cstr? I suspect 
>>> it's actually getting 0 back from lldb-server, which would tell us the 
>>> error is in the server code, not the client code.
>>
>> Ted, I did that and actually the pipe read is returning zero port
>> number. So definitely the issue is on the server side.
>>
>>  GDBRemoteCommunication::StartDebugserverProcess() port_cstr
>> before socket pipe read
>>  GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
>> socket pipe read
>>
>>
>>> Ted's comments are correct and I am guessing we will find the 
>>> "lldb-server gdb-server" is not doing the right thing and it isn't 
>>> returning the correctly bound port.
>>>
>>> 

Re: [lldb-dev] Linking the lldb C++API/library with other projects

[Greg Clayton via lldb-dev]

> 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
xcodebuild -configuration Release

For all others cmake + ninja is the preferred method. Mac builds don't use 
cmake + Ninja as we let Xcode make the LLDB.framework. A framework is a 
directory that contains both the shared library and all public header files 
needed in order for people to link against the LLDB shared library. It is 
possible to build LLDB using cmake + ninja on Mac, but you end up with a 
lldb.dylib shared library instead of a LLDB.framework. The nice thing about the 
LLDB.framework being a directory is that it gives us a place to put all of the 
support binaries that go along with LLDB: lldb-server, darwin-debug (mac only), 
lldb-argdumper, header files needed by clang for expression parsing, python 
modules, and more.

You can see all that is in the framework by doing:

$ find /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework -type f
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/_CodeSignature/CodeResources
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__clang_cuda_cmath.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__clang_cuda_intrinsics.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__clang_cuda_math_forward_declares.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__clang_cuda_runtime_wrapper.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__stddef_max_align_t.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__wmmintrin_aes.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/__wmmintrin_pclmul.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/adxintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/altivec.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/ammintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/arm_acle.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/arm_neon.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/armintr.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx2intrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512bwintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512cdintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512dqintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512erintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512fintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512ifmaintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512ifmavlintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512pfintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vbmiintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vbmivlintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vlbwintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vlcdintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vldqintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avx512vlintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/avxintrin.h
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/Clang/include/bmi2intrin.h

[lldb-dev] [Bug 34183] Remote debugging ARM linux target from x86 linux host - process launch fails

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=34183

Chris Bieneman  changed:

   What|Removed |Added

 CC||chris.biene...@me.com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Chris Bieneman  ---
I've committed a fix in r312008. Can you please see if that resolves the issue
for you?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Linking the lldb C++API/library with other projects

[meister via lldb-dev]

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 and Linux).

lldb is written as a library and in principle this should be possible.   
In practice I’ve had a tough time getting started.  I can build lldb with Xcode 
on OS X.
This is not a criticism - I know resources are limited.  The documentation for 
using the C++ API of lldb are thin and examples are few to non-existent.
I don’t need a lot of help - I would just like a starting point.
I’m developing CANDO, an implementation of Common Lisp that uses llvm as a 
backend  (github.com/drmeister/cando)
I have extensive experience using the llvm/clang API’s within CANDO.

Best,

Christian Schafmeister, Professor
Chemistry Department
Temple University

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

Re: [lldb-dev] lldb-server link failure with shared library configuration

[Tamas Berghammer via lldb-dev]

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 explicit about the list of
dependencies but currently we don't have clear enough boundaries for doing
that. Pavel and Zachary spent some time on improving it but I think we are
still quite far from that.

For your problem I think a better short term option would be to add
LLVMRuntimeDyld as a dependency for lldbExpression instead of lldb-server
directly (assuming it works). Optionally if you are feeling more
adventurous you can try to replace ${LLDB_PLUGINS} and ${LLDB_SYSTEM_LIBS}
with a more explicit list of dependencies what might remove the dependency
between lldb-server and LLVMRuntimeDyld but I am not certain.

Tamas

On Mon, Aug 28, 2017 at 6:00 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> If we are pulling in the expression parser, that would explain our issues.
> If this currently happens in lldb-server we need to add LLVMRuntimeDyld to
> the link libraries. I know some people at Google have looked into getting
> lldb-server to link against as little as possible, and maybe this is just
> how things are for the time being. We should verify that. It would be nice
> if lldb-server didn't link against the expression parser if possible.
>
> Greg
>
> On Aug 28, 2017, at 9:56 AM, Peeter Joot 
> wrote:
>
> Hi Greg,
>
> IRExecutionUnit.cpp looks like the origin of at least some of the
> undefined symbols:
>
> .../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined
> reference to `vtable for llvm::RTDyldMemoryManager'
>
>
> .../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference
> to `vtable for llvm::JITSymbolResolver'
>
>
> .../llvm/include/llvm/ExecutionEngine/RuntimeDyld.h:96: undefined
> reference to `vtable for llvm::RuntimeDyld::MemoryManager'
>
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x90):
> undefined reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0xa8):
> undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x118):
> undefined reference to `llvm::JITSymbolResolver::anchor()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60):
> undefined reference to `llvm::RuntimeDyld:
>
> :MemoryManager::anchor()'
>
> there are a couple of undefined vtable references in headers (also above),
> but it's not clear to me if these also neccessarily come from
> IRExectionUnix.cpp.
>
> --
> Peeter
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev