[lldb-dev] Possible bug in CommandObjectMultiword::Execute

In the case where there is a sub_command, we execute this code: if (sub_cmd_obj != nullptr) { // Now call CommandObject::Execute to process and options in // 'rest_of_line'. From there the command-specific version of Execute will // be called, with the processed arguments. args

Re: [lldb-dev] logging in lldb

On Fri, Dec 9, 2016 at 4:00 AM Jason Molenda via Phabricator < revi...@reviews.llvm.org> wrote: > > I'm not thrilled with the formatv reinvention of format specification. > The printf formatters are a bizarre little invention, but it's a bizarre > invention that we've all worked with for decades a

Re: [lldb-dev] logging in lldb

On Fri, Dec 9, 2016 at 7:36 AM Zachary Turner wrote: > > On Fri, Dec 9, 2016 at 4:00 AM Jason Molenda via Phabricator < > revi...@reviews.llvm.org> wrote: > > > I'm not thrilled with the formatv reinvention of format specification. > The printf formatters are a bizarre little invention, but it's

Re: [lldb-dev] logging in lldb

Chiming in over here to say that I put up a revision which adds formatv support to various parts of llvm. Along with this, I've provided a formatter for `FileSpec` so that we can now print FileSpecs as easily as we would print integers, with various options for pr

Re: [lldb-dev] [RFC] Delete the "testcases" symlink

The reason they were put into the packages directory in the first place is because this forms a proper python package so that more code can be shared amongst test cases. I don't know why the symlink was ever created in the first place, sounds like that was probably put in place by someone who thou

Re: [lldb-dev] [RFC] Delete the "testcases" symlink

if we could remove that long path and move the test > cases back into the test directory. > > Jim > > On Dec 15, 2016, at 9:45 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > The reason they were put into the packages directory in the first p

Re: [lldb-dev] Prebuilt binary for Windows

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 wrote: > Zachary, > Can you please take a look at that change? ( > https://reviews.llvm.org/D27476) > > It'll be sad if another snapshot buil

Re: [lldb-dev] Prebuilt binary for Windows

I will commit it, in the meantime can you request commit access so that any future patches you can commit? On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov wrote: > Thanks! > > Would anyone be so kind to commit that? > > On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner > wrote: > > Sorry, a combina

Re: [lldb-dev] test decorator working on linux, but not on windows

You will probably need to debug the python code to figure out why this is happening. Start with this line in lldb/packages/Python/lldbsuite/test/decorators.py def _decorateTest(mode, bugnumber=None, oslist=None, hostoslist=None, compiler=None, compiler_version=N

Re: [lldb-dev] Prebuilt binary for Windows

It sounds like the solution to the problem is to downgrade SWIG on the build machine. If it's using version 3.0.9 or higher, just use whatever the last version before that is. 3.0.8, for example. At least there's a good workaround in the interim (i.e. setting PYTHONPATH) On Tue, Jan 10, 2017 at

Re: [lldb-dev] logging in lldb

On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > Happy new year everyone. :) > > I have refreshed the implementation at > with something more polished. I > consider this almost-ready, I just need feedback on a couple of > details: > > - log->Warning/Debug/Er

Re: [lldb-dev] Prebuilt binary for Windows

Is static CRT even still supported / recommended when using the new Universal CRT? My understanding is the new UCRT is considered a core windows component, so we don't ahve to distribute redistributables anymore. Maybe I'm wrong about this. That said, I think we want dynamic regardless, otherwis

Re: [lldb-dev] Prebuilt binary for Windows

app or > by VS itself. As long as that is preserved, feel free to do whatever you > need. > > I think we still want to link vcruntime140 statically and the C++ runtime > statically, for example. > > On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev < > lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

gt; > > On Wed, Jan 11, 2017 at 10:51 AM, Reid Kleckner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > The purpose of linking the CRT statically was to ensure that clang can run > on systems that don't have the CRT already installed from some other app or

Re: [lldb-dev] Prebuilt binary for Windows

On Wed, Jan 11, 2017 at 1:47 PM Vadim Chugunov wrote: > > Definitely seems CRT / Python related. The call to fgets indicates that > it's doing something involving a FILE*. It's probably a FILE* that refers > to a file created from within Python's copy of the CRT. > > Any idea where in the code

Re: [lldb-dev] Prebuilt binary for Windows

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 as an extension module. And if it's a dll and uses static linking, then we would hav

Re: [lldb-dev] RTTI does not work stable in LLDB.

Doesn't the DWARF have a record for the VTable itself? I know PDB does, you can look up the class name through the VTable debug info record rather than trying to demangle the name. On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Yeah, when doing dynam

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

Why doesn't llvm::call_once() just use std::call_once on Windows? On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg wrote: > The Win64 lldb build seems broken (at 294367). > > I ran into this when trying to build the weekly snapshot > (http://www.llvm.org/builds/) which includes LLDB these days. > >

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

at the original bug was to know if it has been fixed. On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner wrote: > It's a sad story. Read the comments and the review threads. It's hilarious. > > On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev < > lldb-dev@lis

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2015, is it > time to reconsider? I don't see any links to an MS Connect issue, so I > don't know what the original bug was to know if it has been fixed. > > > On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner wrote: > > It's a sad story. Read the comments and th

[lldb-dev] About lldbHost

After https://reviews.llvm.org/D29964, we finally have a starting point at which we can begin unravelling the cross-project cyclic dependencies in LLDB. lldb/Utility now is very similar in spirit to llvm/Support. But llvmSupport goes one step further and includes what lldb would normally put unde

Re: [lldb-dev] About lldbHost

y of any other > refactoring we will be doing. > > What do you think? > > > > On 15 February 2017 at 01:48, Zachary Turner via lldb-dev > wrote: > > After https://reviews.llvm.org/D29964, we finally have a starting point > at > > which we can begin unravellin

Re: [lldb-dev] About lldbHost

about this idea is that we will end up with > >> two classes that very closely mirror llvm functionality (FileSpec is a > >> version of Support/Path.h that does not assume host path syntax, > >> FileSystem is similar to Support/FileSystem.h, but it supports some > >

Re: [lldb-dev] About lldbHost

ieve this is the reason the FileSystem pseudo-class > >>>>> was created. > >>>>> > >>>>> So, my counter-proposal would be to finish moving the host-specific > >>>>> things out of the FileSpec class (basically just replace > &

Re: [lldb-dev] About lldbHost

is the reason the FileSystem pseudo-class > >>>>> was created. > >>>>> > >>>>> So, my counter-proposal would be to finish moving the host-specific > >>>>> things out of the FileSpec class (basically just replace > >>>&g

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 10:47 AM Reid Kleckner wrote: > On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > I am fine with switching mmap over to llvm if it works. One important > thing to LLDB is we have a "mmap if not on remote file system" that m

Re: [lldb-dev] About lldbHost

If you only ever call MemoryMapContentsIfLocal, then is that first flag even doing anything? And if you are passing that flag, then can you just mmap it always even if non-local? I searched the code and only in the windows minidump plugin are we unconditionally mmaping, and that could be changed

Re: [lldb-dev] About lldbHost

Yea, the flag seems like one you would want to use almost always, so I'm not opposed to having it. I'll see about making the changes in LLVM, even if we end up not using it in LLDB, they seem useful in LLVM independently. BTW, one difference in LLVM's mmap code is that in LLDB we always use MAP_P

Re: [lldb-dev] About lldbHost

Looked into this a little bit, and it's not a problem AFAICT. LLDB only memory maps in one place, which is from FileSpec::MemoryMapFileContents, and it passes writeable=false. LLVM uses MAP_PRIVATE when writeable==false, so from LLDB's point of view there is no functional change. The writeable c

Re: [lldb-dev] Too many ModuleSP references

No comments on this specifically, but +1 to reducing shared_ptr usage in general. We use way too many, and often it feels like shared_ptr is used as a way to avoid having to think about ownership, which leads to more problems than it solves imo On Tue, Feb 21, 2017 at 9:03 AM Pavel Labath via lldb-

Re: [lldb-dev] About lldbHost

On Wed, Feb 15, 2017 at 11:02 AM Greg Clayton wrote: > > The other thing is on Mac we add new flags to mmap that allow us not to > crash if the backing store (network mount) goes away. There is also a flag > that says "if code signature is borked, please still allow me to read the > file without

Re: [lldb-dev] About lldbHost

emote media, access > beyond > * end-of-file, ...). Missing contents will be replaced with zeroes. > */ > > Are you trying to use them for read-write access? That's all I can see. > > Jim > > > > On Feb 21, 2017, at 1:47 PM, Zachary Turner via lldb-dev &

Re: [lldb-dev] About lldbHost

th zeroes. > */ > > Are you trying to use them for read-write access? That's all I can see. > > Jim > > > > On Feb 21, 2017, at 1:47 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > > On Wed, Feb 1

Re: [lldb-dev] Too many ModuleSP references

On Tue, Feb 21, 2017 at 4:24 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Feb 21, 2017, at 9:10 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > No comments on this specifically, but +1 to reducing shared_ptr usage in > g

Re: [lldb-dev] logic reversal in StackFrame::Disassemble in r287189

Thanks for the heads up, it does indeed look like an issue. Wonder why it was only just now caught. I'll submit a fix shortly. On Mon, Feb 27, 2017 at 4:24 AM Carlo Kok wrote: > I think something went wrong in r287189: > > > https://github.com/llvm-mirror/lldb/commit/dfd7c7c89c00bbffcb130cf51c

Re: [lldb-dev] [LLDB on windows] Win32 API UnDecorateSymbolName not thread safe

Thanks for catching this, should be an easy fix. I'll try to get something in this week On Tue, Feb 28, 2017 at 3:34 AM olizit via lldb-dev wrote: > Hello, > > As written in MSDN documentation > https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms681400%28v=vs.85%29.aspx?f=255&MSPPError=-2

Re: [lldb-dev] [llvm-dev] lldb-mi functionality

Not too much documentation unfortunately, but I'm cc'ing lldb-dev@. Hopefully one of the people who have worked on authoring / maintaining this will see it and chime in. On Fri, Mar 10, 2017 at 7:36 PM Chad Smith via llvm-dev < llvm-...@lists.llvm.org> wrote: > Is there any documentation on what

Re: [lldb-dev] C++ method declaration parsing

If there is any way to re-use clang parser for this, it would be wonderful. Even if it means adding support to clang for whatever you need in order to make it possible. You mention performance, are you certain that clang's parser would be unacceptably slow? +cfe-dev as they may have some more in

[lldb-dev] Is anything using the REPL?

AFAICT this is all dead code. Unless someone is using it out of tree? There is a way to register repl support for various languages, but no code in tree is actually doing this. It's possible I'm just not finding the code though. It appears this code was all added about 18 months ago, and if it h

Re: [lldb-dev] Is anything using the REPL?

ft specific code in llvm.org; the github > repository for swift specific additions. > > > > On Mar 21, 2017, at 6:19 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > AFAICT this is all dead code. Unless someone is using it out of tree

Re: [lldb-dev] Is anything using the REPL?

s at all). > > > > On Tue, Mar 21, 2017 at 6:24 PM Jason Molenda > wrote: > > It's used in the swift lldb, https://github.com/apple/swift-lldb > > > > The idea is to have any non-swift specific code in llvm.org; the github > repository for swift s

Re: [lldb-dev] Is anything using the REPL?

to come up with a good way to get REPL.h to not > #include code from the source tree (and ideally, not #include code from > Commands at all). > >> > >> On Tue, Mar 21, 2017 at 6:24 PM Jason Molenda > wrote: > >> It's used in the swift lldb, https://github.com

Re: [lldb-dev] Is anything using the REPL?

> Jim > > > > On Mar 21, 2017, at 6:44 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Not having written or debugged swift before, what does it give you that > a ScriptInterpreter plugin doesn't? It seems like ScriptInt

Re: [lldb-dev] Is anything using the REPL?

mmands at all). > >>> > >>> On Tue, Mar 21, 2017 at 6:24 PM Jason Molenda > wrote: > >>> It's used in the swift lldb, https://github.com/apple/swift-lldb > >>> > >>> The idea is to have any non-swift specific code in llvm.org; the

Re: [lldb-dev] Is anything using the REPL?

detail. > > They have sufficiently different purposes that requiring the > ScriptInterpreter to be a good "fool around with a supposedly compiled > language interactively" or the "REPL" to be good at programming lldb seems > like it would hamstring both to no clea

Re: [lldb-dev] Is anything using the REPL?

ipulates lldb itself seems like just an > implementation detail. > > > > They have sufficiently different purposes that requiring the > ScriptInterpreter to be a good "fool around with a supposedly compiled > language interactively" or the "REPL" to be good

Re: [lldb-dev] Using LLDB API on windows

As the person who added most of the support for debugging Windows executables, I can tell you that I never tested a MinGW executable (nor was it one of my original goals). It doesn't entirely surprise me that things are behaving this way, but I'm not sure what the exact cause would be off the top

Re: [lldb-dev] Was this an unintended consequence of the Args switch to StringRef's?

That does seem unintentional. Is there any particular reason we want to hint the radix? If you're going to specify 0x anyway, then what value does adding the 16 to the getAsInteger add? On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev < lldb-dev@lists.llvm.org> wrote: > memory write's ar

Re: [lldb-dev] Was this an unintended consequence of the Args switch to StringRef's?

What if you write this: // Explicitly try hex. This will catch the case where there is no 0x prefix. if (entry.ref.getAsInteger(16, uval64)) { // If that fails, let the algorithm auto-detect the radix. This will catch the case where there is a 0x prefix. if (entry.ref.getAsInteger(0, uval64)

Re: [lldb-dev] Was this an unintended consequence of the Args switch to StringRef's?

It is weird, I think everyone hates it. One day I'll try to change it, but since it's used so widely, it's a risky change. If it helps, you can think of the return value as a std::error_code, where the operator bool returns true if there's an error. Like if (std::error_code EC = foo()) handleErro

Re: [lldb-dev] Was this an unintended consequence of the Args switch to StringRef's?

Honestly i think it seems reasonable for getAsInteger to just work in this case, so I'll try to add it to llvm On Thu, Apr 6, 2017 at 10:15 AM Jim Ingham wrote: > BTW, Jason says that sometimes the gdb remote protocol does send 0x > prefaced numbers. Apparently not in the cases which have been c

Re: [lldb-dev] Improve performance of crc32 calculation

Zlib is definitely optional and we cannot make it required. Did you check to see if llvm has a crc32 function somewhere in Support? On Wed, Apr 12, 2017 at 12:15 PM Scott Smith via lldb-dev < lldb-dev@lists.llvm.org> wrote: > The algorithm included in ObjectFileELF.cpp performs a byte at a time >

Re: [lldb-dev] Improve performance of crc32 calculation

It would be nice if we could simply update LLVM's implementation to be faster. Having multiple implementations of the same thing seems undesirable, especially if one (fast) implementation is always superior to some other reason. i.e. there's no reason anyone would ever want to use a slow implemen

Re: [lldb-dev] Improve performance of crc32 calculation

BTW, the JamCRC is used in writing Windows COFF object files, PGO instrumentation, and PDB Debug Info reading / writing, so any work we do to make it faster will benefit many parts of the toolchain. On Wed, Apr 12, 2017 at 12:42 PM Zachary Turner wrote: > It would be nice if we could simply upda

Re: [lldb-dev] Improve performance of crc32 calculation

It seems like the the crc32_combine is not too hard to implement, but we do already have code in LLVM that is predicated on the existence of zlib, so it seems reasonable to leave it that way. And yes, you would submit those changes to llvm-dev. Perhaps the JamCRC implementation could be updated t

Re: [lldb-dev] Linux issues where I am not getting breakpoints...

On Wed, Apr 12, 2017 at 10:43 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > What I now believe is happening is lldb-server is exiting for some reason > and then the process just runs and still shows the output in LLDB because > we hooked up the STDIO. I see lldb-server exits wit

Re: [lldb-dev] Improve performance of crc32 calculation

I know this is outside of your initial goal, but it would be really great if JamCRC be updated in llvm to be parallel. I see that you're making use of TaskRunner for the parallelism, but that looks pretty generic, so perhaps that could be raised into llvm as well if it helps. Not trying to throw e

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

The change was made to make the interface safer and allow propagation of StringRef through other layers. The previous code was already taking a const char *, and so it was working under the assumption that the const char* passed in came from a ConstString. As such, continuing to make that same as

Re: [lldb-dev] Command history query

I'll take a look On Wed, Apr 19, 2017 at 10:33 AM Jim Ingham via lldb-dev < lldb-dev@lists.llvm.org> wrote: > No, this was an inadvertent side effect of rewriting the command parser to > use llvm's StringRef's. Please file a bug (or submit a patch!) > > Jim > > > On Apr 18, 2017, at 10:49 PM, vi

Re: [lldb-dev] Command history query

Scratch that, looks like you already fixed this. On Wed, Apr 19, 2017 at 4:50 PM Zachary Turner wrote: > I'll take a look > > On Wed, Apr 19, 2017 at 10:33 AM Jim Ingham via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> No, this was an inadvertent side effect of rewriting the command parser

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

It doesn't entirely defeat the purpose, it's just not *as good* as making the interfaces take ConstStrings. StringRef already has a lot of safety and usability improvements over raw char pointers, and those improvements don't disappear just because you aren't using ConstString. Although I agree t

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

#2 is preferred. When you do it, make sure to add lldb-commits in the subscribers field. You're also free to add specific people to the reviewers field, but the mailing list specifically has to be on subscribers. Unfortunately, due to what I assume are bugs in Phabricator, if you don't get the s

Re: [lldb-dev] Parallelizing loading of shared libraries

Under what conditions would a worker thread spawn additional work to be run in parallel and then wait for it, as opposed to just doing it serially? Is it feasible to just require tasks to be non blocking? On Wed, Apr 26, 2017 at 4:12 PM Scott Smith via lldb-dev < lldb-dev@lists.llvm.org> wrote: >

[lldb-dev] Renaming lldb_private::Error

I have a patch locally that renames lldb_private::Error to lldb_private::LLDBError. As you might expect, this is a pretty large patch so I don't plan to put it up for review, but since it's kind of a fundamental class I figured I should at least start a discussion. The primary motivation for this

Re: [lldb-dev] Renaming lldb_private::Error

I think it should be fairly easy to keep interoperability with SBError. SBError just wraps an lldb_private::Error, so as long as we can construct some implementation of ErrorInfoBase from an SBError, we should be good to go. As an extreme example, we could keep LLDBError exactly as is and provide a

Re: [lldb-dev] Parallelizing loading of shared libraries

Have we examined llvm::ThreadPool to see if it can work for our needs? And if not, what kind of changes would be needed to llvm::ThreadPool to make it suitable? On Fri, Apr 28, 2017 at 8:04 AM Scott Smith via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hmmm ok, I don't like hard coding pools.

Re: [lldb-dev] Parallelizing loading of shared libraries

#1 is no big deal, we could just allocate one in a global class somewhere. #2 actually seems quite desirable, is there any reason you don't want that? #3 seems like a win for performance since no locks have to be acquired to manage the collection of threads On Sun, Apr 30, 2017 at 9:41 PM Scott S

Re: [lldb-dev] Renaming lldb_private::Error

On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote: > I'm mostly but not entirely tongue in cheek wondering why we aren't > calling llvm::Error llvm::LLVMError, as the lldb error class much preceded > it, but that's a minor point. > FWIW I think the naming chosen by LLVM is correct. It's intended

Re: [lldb-dev] Renaming lldb_private::Error

The rename is just to avoid the spelling collision. Nothing in particular leads me to believe that unchecked errors are a source of major bugs. That said, I have some short term plans to begin making use of some llvm library classes which deal in llvm::Error, and doing this first should make thos

Re: [lldb-dev] Renaming lldb_private::Error

I think we agree about the SB layer. You can't have mandatory checking on things that go through the SB API. I think we could code around that though. Regarding the other point, I actually think force checked errors *help* you think about how to back out and leave the debug session alive. Specif

Re: [lldb-dev] Renaming lldb_private::Error

Does Xcode ship with a build of LLDB that has asserts enabled? Because if not it shouldn't affect anything. If so, can you shed some light on why? On Mon, May 1, 2017 at 3:08 PM Jim Ingham wrote: > > > On May 1, 2017, at 2:51 PM, Zachary Turner wrote: > > > > I think we agree about the SB lay

Re: [lldb-dev] Renaming lldb_private::Error

I'm confused. By having the library assert, you are informed of places where you didn't do a good job of backing from errors, thereby allowing you to do a *better* job. You said this earlier: > But a larger point about asserting as a result of errors is that it makes it seem to the lldb develope

Re: [lldb-dev] Renaming lldb_private::Error

Yea, grouping the error and the result together is one of the most compelling features of it. It's called Expected, so where we would currently write something like: int getNumberOfSymbols(Error &Err) {} or Error getNumberOfSymbols(int &Count) {} You would now write: Expected getNumberOfSymbo

Re: [lldb-dev] Renaming lldb_private::Error

On Mon, May 1, 2017 at 5:27 PM Jim Ingham wrote: > > > On May 1, 2017, at 4:52 PM, Zachary Turner wrote: > > > > Yea, grouping the error and the result together is one of the most > compelling features of it. It's called Expected, so where we would > currently write something like: > > > > int

Re: [lldb-dev] Renaming lldb_private::Error

Is there any chance of introducing something like make_status() into llvm/Error.h, that constructs the llvm::Error in such a way that it still interoperates nicely with everything else? Then instead of Expected you could have WithDiagnostics that enforces the proper semantics. On Mon, May 1, 2017

Re: [lldb-dev] Renaming lldb_private::Error

I suppose, but I'm not sure ErrorAnd captures the intended meaning very well. In any case, that's not super important at this stage since this isn't on the immediate horizon. On Mon, May 1, 2017 at 5:43 PM Lang Hames wrote: > Hi Zachary, > > ... Then instead of Expected you could have WithDiagn

Re: [lldb-dev] Parallelizing loading of shared libraries

I would still very much prefer we see if there is a way we can adapt LLVM's ThreadPool class to be suitable for our needs. Unless some fundamental aspect of its design results in unacceptable performance for our needs, I think we should just use it and not re-invent another one. If there are impr

Re: [lldb-dev] Parallelizing loading of shared libraries

I think that's all the more reason we *should* work on getting something into LLVM first. Anything we already have in LLDB, or any modifications we make will likely not be pushed up to LLVM, especially since LLVM already has a ThreadPool, so any changes you make to LLDB's thread pool will likely h

Re: [lldb-dev] Parallelizing loading of shared libraries

Fwiw I haven't even followed the discussion closely enough to know what the issues with the lldb task runner even are. My motivation is simple though: don't reinvent the wheel. Iirc LLDB task runner was added before llvm's thread pool existed (I haven't checked, so i may be wrong about this). If

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

This is in cmake detection code though, the options you set for your build have no bearing there right? This looks like a bug in cmake to me, perhaps a newer cmake version can fix it? On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > What's the cmake com

Re: [lldb-dev] Lack of parallelism

If you have access to a Windows machine and you can reproduce the slowdown there, there are surprisingly good tools available for diagnosing parallelism and thread contention. https://github.com/google/UIforETW On Tue, May 2, 2017 at 8:09 AM Scott Smith via lldb-dev < lldb-dev@lists.llvm.org> wro

Re: [lldb-dev] Renaming lldb_private::Error

I'm probably going to be looking at submitting this this week, more likely sooner rather than later. If I can get it all working hopefully even tomorrow. On Mon, May 1, 2017 at 5:49 PM Zachary Turner wrote: > I suppose, but I'm not sure ErrorAnd captures the intended meaning very > well. In an

Re: [lldb-dev] Renaming lldb_private::Error

Yes, this is just the rename. Regarding the naming, if you call it ErrorAnd, or WithError, or anything that includes the word error, you are implying that something actually went wrong. I don't think that's the intended use case, or at least not what I have in mind (and from previous conversation

Re: [lldb-dev] Renaming lldb_private::Error

On Wed, May 10, 2017 at 8:33 PM Lang Hames wrote: > Leaving 'Status' aside for now (the rename makes perfect sense), I'm > basing my ErrorAnd / WithError naming suggestion on this comment: > > Is there any chance of introducing something like make_status() into >> llvm/Error.h, that constructs th

Re: [lldb-dev] Renaming lldb_private::Error

This is now done in r302872, btw. I'm only able to test on Windows here, but I didn't see any regressions (not sure why there would be), and there were very few compilation failuers to fix up. So hopefully other platforms don't run into any problems On Wed, May 10, 2017 at 9:02 PM Zachary Turner

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

Again, this has nothing to do with our build files, it is in cmakes internal builtin modules when it is trying to compile a program to see if a symbol exists. This looks like a cmake bug, try upgrading cmake On Mon, May 15, 2017 at 1:25 AM Pavel Labath wrote: > Technically, it's the combination o

Re: [lldb-dev] lldb-server tests

One thing about lit that most people either don't understand or forget about is that FileCheck has nothing to do with lit. You can have lit tests without FileCheck. It's more work because you would have to define an LLDBServerTestFormat and invent some DSL that isn't just a bunch of run lines and c

[lldb-dev] llvm::to_integer

In the past I've advocated for use of StringRef::getAsInteger(). Sometimes this leads to awkward code, for example if you have a std::string you have to write StringRef(Str).getAsInteger(). Secondly, the return value is extremely confusing as it returns true on failure and false on success. I re

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

Hmm, I believe it's only supposed to do that if you're doing a debug build. It should only require the Python libraries that match your current build. Is it not doing this? On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Update: looks like Python

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

On Fri, Jun 30, 2017 at 12:39 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Python support on Windows is much more problematic than support on > something like MacOS or Linux. The python you use when you run lldb must be > the same python used when you build it. Bad things happe

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

On Fri, Jun 30, 2017 at 1:34 PM Ted Woodward wrote: > I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 > .so/library directory, so I’m not willing to say building on Windows with > 3.6.1 and using the 3.5.2 dll/library directory will work. Python has never > been very forgi

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

For clang-cl you need to use -fuse-ld=lld. For msvc only a small amount of pdb support was added to lldb, namely the ability to resolve file and line info. On Wed, Jul 26, 2017 at 12:46 PM Vadim Chugunov wrote: > I'm trying to use LLDB built from svn trunk: for MSVC emitted binaries it > cannot s

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

It can handle linking dwarf debug info. Also I misspoke, you can't get dwarf debug info with clang-cl, but you can with clang++ on windows. Look at how the test suite on windows compiles the inferiors. That's currently the best debugging experience of Windows programs. Unfortunately i was never ab

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

Are we talking about some kind of mi support other than lldb's existing MI interface? Afaik it works reasonably well (for some definition of reasonably well), and is even used for example in msvc on windows to support remote debugging of non windows targets. That said, most lldb developers are pai

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

It might be worth brainstorming if there’s ways to do this that are both intuitive and don’t require more options. As a command line user, I really value my keystrokes. One idea would be to use a syntax that matches that of the ‘-name’ option to the standard ‘find’ utility. This way filename pat

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

Pass a pattern to the -f option. On Tue, Oct 24, 2017 at 7:18 PM Don Hinton wrote: > Do you mean just pass a pattern to the -f option or FileSpec? > > On Tue, Oct 24, 2017 at 6:50 PM, Zachary Turner > wrote: > >> It might be worth brainstorming if there’s ways to do this that are both >> intuit

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

Right, but you can still escape it no? You face the same issue with `find . -name "*"`. That's going to find everything. This is just optimizing usability for the common case. Because it's pretty rare case to want to search for literal *, extremely common to want to search for wildcard stars, a

Re: [lldb-dev] check-lldb will start using in-tree clang by default

Agree we should just build clang as a dependency. We're already building most of it anyway since we require it for the expression parser, so spitting out the executabatle as well should not be too controversial. On Fri, Oct 27, 2017 at 12:58 PM Davide Italiano via lldb-dev < lldb-dev@lists.llvm.o

Re: [lldb-dev] check-lldb will start using in-tree clang by default

Maybe make it a dependency of the `check-lldb` target instead of the `lldb` target? On Fri, Oct 27, 2017 at 1:26 PM Davide Italiano wrote: > I'm testing with the following change. > Should I shove the dependency instead in test/CmakeLists.txt ? > > $ git diff HEAD > diff --git a/CMakeLists.txt b

Re: [lldb-dev] check-lldb will start using in-tree clang by default

One more nitpick. Can you make it a dependency of `check-lldb-lit` target also? Just for the sake of pedantry. On Fri, Oct 27, 2017 at 2:04 PM Pavel Labath wrote: > Ship it. > > On 27 October 2017 at 13:56, Davide Italiano > wrote: > > Take 2 (it can't be in the top-level CMakeList because th

<    1   2   3   4   5   6   7   >