[lldb-dev] lldb debug jit-compiled code with llvm on windows

hi, process A generate function Func1 code with llvm jit compiler, and calls Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug information. how to use LLDB to attach process A to debug this function, add a breakpoint in the function? thanks!___

Re: [lldb-dev] lldb debug jit-compiled code with llvm on windows

In theory you don't have to do anything special to debug some JIT-ed code as everything should just work (based on the gdb jit interface). In practice I tried it out a few days ago and it wasn't working at all even in the case when the application is launched under LLDB (not with attach). LLDB was

Re: [lldb-dev] bindings as service idea

For the benefit of continuity in conversation, here is what you had to say about it before: > One possibility (which I mentioned to you offline, but I'll put it here for others to see) is that we make a swig bot which is hosted in the cloud much like our public build bots. We provide a Python scr

Re: [lldb-dev] Auditing dotest's command line options

We're reviewing these. I've added the ones that I use or need for infrastructure. I've pinged everyone else internally and we'll be sure to update any others over today and tomorrow. -Todd On Wed, Nov 18, 2015 at 2:32 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I would

Re: [lldb-dev] bindings as service idea

Just to re-iterate, if we use the bindings as a service, then I envision checking the bindings in. This addresses a lot of the potential pitfalls you point out, such as the "oops, you can't hit the network, no build for you" and the issue of production build flows not wanting to hit a third party

Re: [lldb-dev] LLDB Windows Python Bindings

+lldb-dev since this could be useful to other people. I'm actively working on getting Python 3.5 support working. If you want to go this route, it will make your life much easier. But I don't have a fully passing test suite yet, there are still about 30 failing tests. So consider Python 3.5 exp

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner wrote: > Just to re-iterate, if we use the bindings as a service, then I envision > checking the bindings in. This addresses a lot of the potential pitfalls > you point out, such as the "oops, you can't hit the network, no build for > you" and the

Re: [lldb-dev] bindings as service idea

I wasn't planning on working on this immediately, but given the outcome of the recent static bindings work, I can re-prioritize. I don't know how long it will take, because honestly writing this kind of thing in Python is new to me.. to make an understatement. But I'll get it done. Give me until

Re: [lldb-dev] bindings as service idea

I'm out next week, but I can help if needed after that. Related to all this, you have mentioned a few times that there are newer swig features you want to use. Can you enumerate the features not present in 1.x but present in 3.x that you want to take advantage of, and what benefits they will brin

Re: [lldb-dev] bindings as service idea

Some other points we need to consider on the bindings-as-service idea: * The service should be exposed via secure connection (https/ssl/etc.) This might already be guaranteed on the Google end by virtue of the endpoint, but we'll want to make sure we can have a secure connection. (This will be a

Re: [lldb-dev] bindings as service idea

Well some of the bugfixes are actually worth mentioning, because we actually have bugs on the C++ side that we can't fix because then SWIG won't be able to process the header files. For example, if SWIG sees this in a header file, it errors out and can't even proceed. enum Foo : unsigned { Ba

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner wrote: > Well some of the bugfixes are actually worth mentioning, because we > actually have bugs on the C++ side that we can't fix because then SWIG > won't be able to process the header files. For example, if SWIG sees this > in a header file, it

Re: [lldb-dev] bindings as service idea

I don’t think so, this was just an embedded link to your hard drive: file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types Sean > On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev > wrote: > > > > On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner

Re: [lldb-dev] bindings as service idea

Doh! lol On Thu, Nov 19, 2015 at 10:57 AM Sean Callanan wrote: > I don’t think so, this was just an embedded link to your hard drive: > > file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types > > Sean > > On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev < > lldb-de

Re: [lldb-dev] bindings as service idea

Derp, I forgot C++11 support. Some of it is not useful to us given the limited nature of the SB API, but certain things could be useful. Being able to transition to enum classes is nice, for example. Anyway, there's a lot here, so feel free to read through the document. http://www.swig.org/Doc3.

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote: > Some other points we need to consider on the bindings-as-service idea: > > * The service should be exposed via secure connection (https/ssl/etc.) > This might already be guaranteed on the Google end by virtue of the > endpoint, but we'll want

Re: [lldb-dev] bindings as service idea

The server is sending back code. I'd want to know I can trust whoever is sending me back code that I plan to build and run locally. Jim > On Nov 19, 2015, at 11:40 AM, Zachary Turner via lldb-dev > wrote: > > > > On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote: > Some other points we ne

[lldb-dev] lldb with app using shared lib not working

Hi, if I try to debug an application from the terminal that is using a shared lib lldb complains always about not finding the library even though everything is loading correctly when starting the app directly from the same terminal: echo $DYLD_LIBRARY_PATH/ running with debugger, shared lib can

Re: [lldb-dev] bindings as service idea

>> If so, does this mean everyone needs to generate a cert locally? Generally not - as long as the server is dishing out something over https, the server will be signed with a certificate that is going to be in the local OS's set of trusted root certificates (particularly if this is provided by Go

Re: [lldb-dev] LLDB Windows Python Bindings

-old list +new list On Thu, Nov 19, 2015 at 1:28 PM Zachary Turner wrote: > Python 2.7 literally does not even compile with VS 2015, you would have to > fork it and fix the compilation errors. I've tried to upstream fixes and > they won't accept them, since 2.7 is "dead" except for maintenance

Re: [lldb-dev] bindings as service idea

For our builds at QUIC, we're not interested in hitting an external server to get code. So we'd either hit the server when needed and check in the resultant bindings, or (preferably) use bindings from upstream. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a m

[lldb-dev] FW: LLDB Windows Python Bindings

Why can’t we use VS 2015 with Python 2.7? -- 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 Zachary Turner via lldb-d

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 1:38 PM Ted Woodward wrote: > For our builds at QUIC, we're not interested in hitting an external server > to get code. So we'd either hit the server when needed and check in the > resultant bindings, or (preferably) use bindings from upstream. > Right, and this is actua

Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

I fixed this: % svn commit Sendinginclude/lldb/Symbol/TypeMap.h Sendingsource/Symbol/SymbolContext.cpp Sendingsource/Symbol/TypeMap.cpp Transmitting file data ... Committed revision 253618. > On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev > wrote: > > H

Re: [lldb-dev] FW: LLDB Windows Python Bindings

On Thu, Nov 19, 2015 at 1:39 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Why can’t we use VS 2015 with Python 2.7? > Python 2.7 literally does not even compile with VS 2015, you would have to fork it and fix the compilation errors. I've tried to upstream fixes and they won'