Re: [lldb-dev] Xcode project creates too many diffs if I just add or remove a file...

See Jason’s email from two weeks ago: > I didn't intend for it, but when you add a file to the xcode project file, > Xcode will reorder all the currently-sorted files and we'll get all the same > merge conflicts we've had for the past couple years again. > We could either back out my sorting of

Re: [lldb-dev] Xcode project creates too many diffs if I just add or remove a file...

That’s just how IO redirection works in sh. But I agree that the expected default behavior is to just overwrite the file without having to redirect any streams/tmp files (+ Jason because he probably can easily fix this). - Raphael > On Jul 23, 2018, at 3:24 PM, Greg Clayton wrote: > > The scr

Re: [lldb-dev] [RFC] Removing lldb-mi

I just went forward with this and made a quick test repo with an out-of-tree lldb-mi that compiles against the system LLDB: https://github.com/Teemperor/lldb-mi This seems to work fine with the exception of the python tests which require LLDB’s python code

Re: [lldb-dev] [RFC] Removing lldb-mi

gt; I'll put up another diff to remove the code, which we can land once LLVM 9 > has branched. > > Thank you, > Jonas > > On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > I just went forward

Re: [lldb-dev] [llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style? I’m in general in favor of moving LLDB to the LLVM code style because it makes the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no more co

[lldb-dev] lldb-mi has been moved to its own GitHub repository

Hi all, lldb-mi has been moved out of the LLDB source tree into its own GitHub repository here: https://github.com/lldb-tools/lldb-mi lldb-mi is now a standalone tool that builds against LLDB, but is no longer build as part of LLDB. The implications for

Re: [lldb-dev] Anybody using the GUI?

I’m also in favour of keeping the GUI around. It’s not perfect, but at least in a usable state and not a huge maintenance burden from what I can see. - Raphael > On 25. Aug 2019, at 02:02, Greg Clayton via lldb-dev > wrote: > > I know many people use it. They tend to drop in and use it, and t

Re: [lldb-dev] Any plan to support to debug Webassembly file?

I’m not sure I understand what the question is. Do you want that LLDB attachs to the wasm program running inside your VM and then debug the wasm program via LLDB? Or that LLDB can run the wasm module itself like an executable and then run it/step through it/inspect it/etc.? Cheers, - Raphael >

Re: [lldb-dev] Any plan to support to debug Webassembly file?

+lldb-dev > On 26. Aug 2019, at 12:57, Raphael “Teemperor” Isemann > wrote: > > If I understand correctly your VM is your own custom wasm interpreter/JIT? If > yes, then I don’t think it is realistic that LLDB can ever support it out of > the box. But you can write a LLDB plugin that calls yo

[lldb-dev] [RFC] Restructuring the (command) tests

Hi all, I have to admit I’m getting a bit confused lately where to put tests. Especially for testing LLDB commands it’s not obvious where to put files as we test some commands directly in the top-level test folder (e.g. quit, help, settings), some are in /functionalities with a _command suffix

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

To my knowledge there is no way to have completions for custom commands. If you just want completions for nested commands (e.g., having a “custom add” and “custom remove” commands and want completions for completing “add” and “remove”), then this should work if you build the nested command using

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

Jim just ninja’d the discussion with his point that we could add methods for adding command completions to existing commands and I actually agree that’s the better idea (especially since this is abstracting away the actual option parsing from the user and it can be better integrated into the cur

Re: [lldb-dev] Slow expression evaluation (ASTImporter is too eager?)

Can you post that patch on Phabricator with an '[ASTImporter]’ as a name prefix? This way the ASTImporter folks will see your patch (The ASTImporter is more of a Clang thing, so they might not read lldb-dev). Also it makes it easier to see/test your patch :) (And +Gabor just in case) > On Nov

Re: [lldb-dev] SBValues referencing deallocated memory

This can also be reproduced in the command line like this: (lldb) expr "foo" (const char [4]) $0 = "foo" (lldb) expr "bar" (const char [4]) $1 = "bar" (lldb) expr $0 (const char [4]) $0 = “bar” This however works just fine: (lldb) expr char c[] = "foo"; c (char [4]) $0 = "foo" (lldb) expr char c

Re: [lldb-dev] Stumped on the missing FindExternalLexicalDecls call

Sorry for the late reply. Can you share a reproducer for this with upstream LLDB? Otherwise it would also help if you could share a backtrace for when LLDB calls the correct FindExternalLexicalDecls (that way we know if this was coming from just Clang’s normal parsing process or if there is some

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

I think this is great, thanks for working on this! My only concern is that I would prefer if we could limit the Lua tests to just the Lua->C++ calling machinery (e.g., that we handle Lua strings correctly and all that jazz) and not fragment our test suit. Otherwise Lua seems to require far less

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

I don’t think we ever received a reproducer for this that would allow us to investigate this (or write a fix). - Raphael > On 8. Dec 2019, at 23:02, Vadim Chugunov via lldb-dev > wrote: > > Looks like I am hitting the same issue. Was there a fix checked in for this? > > On Thu, Mar 7, 2019

[lldb-dev] The future of modern-type-lookup in LLDB

Hi, some of you may have seen that I’ve been working on the ‘modern-type-lookup’ mode in LLDB over the last months. I thought it’s a good time now to start a discussion about what’s the current state, goals and the future of this feature. Some background about the topic to get everyone on the s

Re: [lldb-dev] How to preserve command history?

LLDB is explicitly creating the .lldb directory for the user (see Editline.cpp -> GetHistoryFilePath). Is this also happening in a more recent LLDB version? It’s working for me on the latest release on Arch. > On Apr 20, 2020, at 4:34 PM, Andrzej Warzynski via lldb-dev > wrote: > > Hello, >

Re: [lldb-dev] [RFC] Listing files in remote directory

I think classifying into local/platform isn't an issue (I think we always know if we're doing remote or local completion), but the bigger problem is that I'm not sure if we can easily list files/subdirs in a remote directory. I didn't find any existing functionality that's doing this, so I guess

[lldb-dev] [RFC] Moving away from epydoc for the LLDB SB API documentation

Hi all, some of you might have noticed that the Python SB API documentation on the website hasn't been regenerated since more than a year. I pinged Andrei about fixing the broken generation script. While I was trying to recreate the doc generation setup on my machine I noticed that our document

Re: [lldb-dev] Logging for multiple targets

Two problems that I can see: * Log depends on no other part of LLDB. But nearly everything in LLDB depends on Log. So if we give Log a Target/ExeCtxt then all of LLDB would now depend on lldbTarget. * IIRC our global log instance is shared between all debuggers/targets. So I'm not sure if adding

[lldb-dev] The SB API documentation migrated to sphinx

Hi all, some of you might have noticed that over the weekend we migrated the SB API documentation over to sphinx: https://lldb.llvm.org/python_api.html This change will require some (minor) changes to the current workflow: 1. docstrings in the SWIG (*.i) files should be written in reStructuredTe

Re: [lldb-dev] reviewer requested for D101250

Done. There is an `LLDB` review group you can also add as a review if you are unsure who should review (or you think anyone can review). - Raphael > On 26 Apr 2021, at 23:53, Neal Sidhwaney via lldb-dev > wrote: > > Hello, > > I put together a small patch for the Editline wrapper in LLDB: >

Re: [lldb-dev] lldb-sphinx-docs builder is failing

Hi Tom, yes, the bot has been failing since a long time but I couldn't reach Dmitri (who is I think maintaining it). For the record, the required dependencies for the LLDB docs are: * Python 3 development headers (Something like python3-dev should be enough) * SWIG (at least version 3). * the sp

Re: [lldb-dev] SB API questions

Thanks! In the spirit of not letting users fix our bugs, I just made a draft patch for the logging enable/disable: https://reviews.llvm.org/D103376 I don't think landing code is much of a burden, but I think you can just re-request commit access if you had it before. Cheers, - Raphael > On 30

Re: [lldb-dev] Reporting bugs which only affect (semi-proprietary) downstream consumers.

Hi Adam, I think the best idea is to comment on the commit on Phabricator ( reviews.llvm.org ) as it seems to be a relatively recent change. Otherwise if you can somehow provide way to reproduce the deadlock using only code you can share + LLVM.org sources then filing a bug would be an option t

Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper

What libedit version/port is Fedora using? I think the usual Linux port[1] is suffering from two issues: One is that most unicode characters with code points <= 256 are mapped to ‘unassigned’ instead of ‘insert character’ which prevents them from being entered. Why the other characters are just

Re: [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper

Maybe mariadb is not using libedit in emacs mode? LLDB also provides a custom callback for libedit to read characters from the command line (which mariadb probably doesn’t), so maybe we implemented that incorrectly. - Raphael > On 11 Jul 2021, at 13:45, Jan Kratochvil wrote: > > On Sun, 11 J

Re: [lldb-dev] who is maintaining lldb-x86_64-debian

If this is about the TestGuiBasicDebug failures, then that test is also failing on other bots. I personally would vote to disable the test as that part of the test is flakey since its introduction (which was during this GSoC). - Raphael > On 2 Sep 2021, at 12:27, Omair Javaid via lldb-dev > w