[lldb-dev] Catching async debugger output

Hello, Is there a way for a python script to catch asynchronous debugger output, such as the output of stop hooks? I've tried attaching a listener to CommandInterpreter's broadcaster, but no events seem to be ever fired. Anything else I should try? thanks!

[lldb-dev] Spurious process state change events

Hi, I have a Python script that drives LLDB (in async mode), with a listener attached to the process. On OSX, upon the launch, LLDB emits a eStateRunning process state event, and then eventually eStateStopped - when a breakpoint is hit. On Linux, however, the initial eStateRunning is immediately

Re: [lldb-dev] Spurious process state change events

wrong, but I believe that every restarted >> should be then followed by a running event. >> >> cheers, >> pl >> >> >> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> > Hi, >

Re: [lldb-dev] Selectively disabling value formatter

On Mon, Jan 25, 2016 at 11:04 AM, Enrico Granata <egran...@apple.com> wrote: > > On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi, > If I have an SBValue for an object whose type has a formatter enabled for

Re: [lldb-dev] Selectively disabling value formatter

lldb-340.4.119 (OSX 10.11.3) On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra <sivachan...@google.com> wrote: > On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi, > > If I have an SBValue for an object whos

Re: [lldb-dev] Prebuilt binary for Windows

.org/bugs/show_bug.cgi?id=31699> for now. On Thu, Jan 12, 2017 at 4:12 PM, Reid Kleckner <r...@google.com> wrote: > On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I was referring to this: https://support.micr

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

id Kleckner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> I imagine that Hans doesn't have Python 3 installed on his system, so >> LLDB didn't autoconfigure with Python support. >> >> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev < >&

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

to take when making the prebuilt binary so >> that it >> >> works next time. >> >> >> >> >> >> >> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov <vadi...@gmail.com> >> wrote: >> >> >> >>

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

is a problem with the way we built lldb. I will look into >> what >> >> additional steps we need to take when making the prebuilt binary so >> that it >> >> works next time. >> >> >> >> >> >> >> >> On Tue, Oct 11,

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

ough to point > >> to your Python 3.5 installation though and see if it fixes it? (I don't > >> think it will, but let's try anyway) > >> > >> > >> > >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov <vadi...@gmail.com> > wrote: > >

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

e? >> >> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> I imagine that Hans doesn't have Python 3 installed on his system, so >> LLDB didn't autoconfigure with Python support. >> >> On Sun,

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

> Does the 4.0 binary not work for you? It is the first release that contains prebuilt lldb binary. Looks like the Python API is not included though. Do you know why it was left out? ___ lldb-dev mailing list lldb-dev@lists.llvm.org

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

This seems to work: https://reviews.llvm.org/D27476 On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg wrote: > The only thing needed to build the installer should be having NSIS > installed and building the "package" target generated by CMake. The > other prerequisites are

Re: [lldb-dev] Prebuilt binary for Windows

On Wed, Jan 11, 2017 at 3:54 PM, Zachary Turner wrote: > Ahh, that would make sense as well, since LLDB links against liblldb as a > dll. Don't see a good solution to this short of forcing dynamic linking. > liblldb has to be a dll because it needs to be visible to python

Re: [lldb-dev] Prebuilt binary for Windows

It worked! ...but not before I set PYTHONPATH=C:\Program Files (x86)\LLVM\lib\site-packages\lldb Without that, it couldn't find the _lldb module, so we are not quite out of the woods yet. When are you planning to make the next snapshot build? Thanks! On Mon, Jan 9, 2017 at 3:48 PM, Hans

Re: [lldb-dev] Prebuilt binary for Windows

BTW, here's the call stack at the point of failure. I don't see anything Python-related in it, so maybe it's some other CRT interaction. liblldb!_invoke_watson(wchar_t * expression = 0x "", wchar_t * function_name = 0x "", wchar_t * file_name = 0x "", unsigned int

Re: [lldb-dev] Prebuilt binary for Windows

Yes, the new build works! On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg wrote: > I've downgraded my swig to 3.0.8 and built a new snapshot (r291454). > Please let me know if that works. > > On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner > wrote: > > It

Re: [lldb-dev] Prebuilt binary for Windows

Sorry, just found another problem: the installed lldb crashes when given a script via the command line. For example, `lldb -O "p 42"` dies with exception 0xC409. It didn't happen with the one I've build locally, so I started digging... The difference seems to be that

Re: [lldb-dev] Prebuilt binary for Windows

This appears to be a SWIG bug: https://github.com/swig/swig/issues/769 On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov wrote: > It worked! > > ...but not before I set PYTHONPATH=C:\Program Files > (x86)\LLVM\lib\site-packages\lldb > Without that, it couldn't find the _lldb

Re: [lldb-dev] Prebuilt binary for Windows

I was referring to this: https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows. Granted, it was probably marked as non-critical, so some users may have skipped it. > One of the redist options is to include an MSU in your installer that tells Windows Update

Re: [lldb-dev] Prebuilt binary for Windows

Okay, as far as I can see, the issue is not with Python, but that lldb.exe and liblldb.dll have their own private copies of the CRT. When startup script is given on the command line, lldb.exe creates a pipe, writes the script into the write end, wraps a stdio file around the read end, and gives

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

Hi Hans, I'd love to help, but I don't have half the tools that build_llvm_package.bat requires installed on my machine. My setup is to build llvm with msbuild. Is it possible to build the installer this way too? Can you point me to the specific CMake source that determines what's included in

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

I am having no luck building LLDB with ninja, and there doesn't seem to be a "package" target in the generated msbuild solution file, but here's something interesting I found in cmake

[lldb-dev] Prebuilt binary for Windows

Zachary, Can you please take a look at that change? (https://reviews.llvm.org/D27476) It'll be sad if another snapshot build gets published with broken lldb. :( On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov wrote: > This seems to work: https://reviews.llvm.org/D27476 > >

Re: [lldb-dev] Prebuilt binary for Windows

Thanks! Would anyone be so kind to commit that? On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner wrote: > Sorry, a combination of national holidays and extended vacations happened > and this fell off my radar. lgtm > > On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov

Re: [lldb-dev] PDB symbol reader status?

ace, print variable > values, etc. > > > On Wed, Jul 26, 2017 at 11:19 AM, Vadim Chugunov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi, >> What is the current status of LLDB's PDB file parser on Windows? It was >> anno

Re: [lldb-dev] Python scripting in Windows LLDB

Note that building with 3.6.x and using 3.5.x won't work, but any of 3.5.x revisions should be compatible between themselves. On Fri, Jun 30, 2017 at 1:41 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Fri, Jun 30, 2017 at 1:34 PM Ted Woodward

Re: [lldb-dev] PDB symbol reader status?

gt;>>>> I'm currently working on a native PDB reader that implements the same >>>>> interface without reliance on DIA, so that should eventually provide the >>>>> same functionality even if you're not running on Windows. >>>>> >>>>>

[lldb-dev] Forcing lldb to refresh process state

Hi, Is there any way to force lldb to refresh it's internal record of debuggee process state (as if it had just received a stop event)? I want to send a custom command to remote gdb process stub (via `process plugin packet send`). This works, but if the command alters debuggee state, lldb won't

Re: [lldb-dev] Forcing lldb to refresh process state

ing...@apple.com> wrote: > >> > >> No, there hasn't been a need for this. > >> > >> What commands are you planning to send? Or equivalently, how much > state are you expecting to change? > >> > >> Jim > >> > >>> On Aug 18, 2017,

[lldb-dev] Python scripting in Windows LLDB

Hi! I've just noticed that LLDB from the most recent LLVM Windows snapshot build has Python scripting disabled. Was this done on purpose and for what reason if so? ___ lldb-dev mailing list lldb-dev@lists.llvm.org

Re: [lldb-dev] Python scripting in Windows LLDB

Update: looks like Python detection in CMake now requires debug binaries to be there as well (e.g. python35_d.dll), otherwise Python support gets disabled. I am wondering if Python the build machine was installed without the debug stuff. On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov

Re: [lldb-dev] Forcing lldb to refresh process state

Yeah, this `bs` + `stepi` dance is the only workaround I found so far. On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton wrote: > There is a standard for reverse stepping where the GDB remote protocol was > extended to do the reverse stepping. See: > >

Re: [lldb-dev] Forcing lldb to refresh process state

On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton wrote: > This isn't a work around right? You should be triggering your reverse step > or reverse continue using a "process reverse-continue" or "thread > reverse-step" right? If you do this, everything will just work. There >

Re: [lldb-dev] How to test lldb-vscode?

FYI - I've been maintaining a similar VSCode extension , which does it all through LLDB's Python interface. As for testing, the protocol is JSON with HTTP-like headers for framing, so you could have a Python script emulating

Re: [lldb-dev] How to test lldb-vscode?

My tests are here . I probably wouldn't move all that to Python for my extension, but feel free to draw ideas on things to test from it. What's going to be your deployment story? The nice thing about

[lldb-dev] PDB symbol reader supports C++ only?

Hi! I've been investigating why LLDB refuses to set breakpoints in Rust source files when using PDB debug info on Windows... This seems to stem from a couple of checks here

Re: [lldb-dev] PDB symbol reader supports C++ only?

Would you mind going into a bit more detail on what sort of problems an unknown language could cause? I'd like to understand the issue before jumping in to fix anything. AFAIK, in the case of DWARF symbols, debug info for unknown languages is still used, so it wouldn't be the first for LLDB...

Re: [lldb-dev] PDB symbol reader supports C++ only?

Mon, Aug 27, 2018 at 6:32 AM Tom Tromey wrote: > >>>>> "Vadim" == Vadim Chugunov via lldb-dev > writes: > > Vadim> Would you mind going into a bit more detail on what sort of > Vadim> problems an unknown language could cause? I'd like to understand

[lldb-dev] Cross-building lldb

Hi, I'm trying (and failing) to cross-build lldb according to these instructions . My cmake command line: cd /workspace/build/lldb && /usr/bin/cmake -DLLVM_VERSION_SUFFIX=-custom

[lldb-dev] Rust support in LLDB, again

Hi, Last year there was an effort led by Tom Tromey to add Rust language support into LLDB. He had implemented a fairly complete language plugin, however it was not accepted into mainline because of supportability concerns.I guess these concerns had some merit, because this change did not

Re: [lldb-dev] Rust support in LLDB, again

> > > Unless my memory is failing me, I don't think we ever explicitly > > rejected Rust's language plugin. We removed a few other language > > plugins (Go, Java) that were not maintained and were becoming an > > increasing burden on the community. At the same time we agreed that we > > didn't

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

FWIW, Python provides stable ABI for a subset of their API. I've actually managed to create a version of LLDB that is Python-optional and Python version-agnostic (for versions 3.3 up). Though given the number of hoops I had to jump through to get

Re: [lldb-dev] Setting environment via SBLaunchInfo

nyway. If the host and target are different OS'es and maybe > different users, etc. lldb's environment may very well not be appropriate > for the target process. > > JIm > > > > On Nov 26, 2019, at 6:13 PM, Vadim Chugunov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: &g

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

Looks like I am hitting the same issue. Was there a fix checked in for this? On Thu, Mar 7, 2019 at 3:05 PM Raphael Isemann via lldb-dev < lldb-dev@lists.llvm.org> wrote: > You can also dump() the AST to a file on disk if that is easier to > capture than stderr. See the overload of `dump()`

Re: [lldb-dev] Rust support in LLDB, again

Hi Greg, So if Rust doesn't use clang in its compiler > - create a new TypeSystem for Rust that would convert DWARF into Rust AST > types that are native to your Rust compiler that uses as much of the Rust > compiler sources as possible > - write a native Rust expression parser which hopefully

Re: [lldb-dev] Rust support in LLDB, again

On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton wrote: > Yeah this is a tough tradeoff as this is what GDB does or at least did the > last time I was working on it. In most debuggers, they make up their own > internal type representation, and have a generic LALR recursive descent > parser to

[lldb-dev] Setting environment via SBLaunchInfo

Hi, I am trying to figure out the proper way of using LLDB's SBLaunchInfo class: When I launch a process via CLI interpreter, it seems to receive all of the environment variables inherited from shell, plus the ones I set via `target.env-vars`: (lldb) file /usr/bin/env Current executable set to

[lldb-dev] LLDB SBAPI questions

Hi, I've a couple of questions: 1. Is there a way to get numeric values of C++ template parameters? SBType has a method for discovering argument kind and type, but I couldn't find anything for values. 2. Can I enumerate static variables of a class via SBType? (and read their values) thanks!

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

Not sure if this is a supported configuration, but I am hitting this error when compiling on Ubuntu 16.04 with clang 12: FAILED: /usr/local/bin/clang++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

return false; > result->second.ThreadDestroyed(nullptr); > m_plans_list.erase(result); > return true; > } > > But the iterator of a map shouldn't require a copy of the value, that > doesn't make sense. > > Other than that, I can't see anything funny

[lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

Hi, I am observing that if I bind a synthetic provider to MyType, it will also be instantiated for MyType*, MyType**, etc, and the object passed into the constructor will be *of the pointer type*.I'd have expected the synthetic to either not be instantiated for pointers, or to be constructed

Re: [lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

On Mon, Jul 19, 2021 at 6:02 PM Jim Ingham wrote: > You can control whether you want data-formatters on "class Foo" to also > match "class Foo *" and "class Foo &" using the --skip-pointers and > --skip-references options respectively. > So this part is clearly is by design. > > As for what the