How is this class different from lldb_private::CleanUp? Shouldn't we just delete it and replace all uses with the pre-existing class?
Rebase this patch on trunk. Now this patch is simply about moving GetPythonDir
from Host module to ScriptInterpreterPython.
Looks good. My only question is do we not require people to only fill in the directory portion of the FileSpec anymore for these functions? I am fine with way since hopefully FileSpec::AppendPathComponent handles things correctly.
Mon, Jun 18
I also don't want to get involved too much, but here are my 2c: :)
Another example might be if you were writing a debugger which was debugging N processes simultaneously, and due to various OS restrictions, each of these N processes was being debugged by a separate thread.
Looks good. I'm really happy with how this turned out. Thank you for your patience.
Fri, Jun 15
This is looking very good, I just have one more quick question. I am wondering whether we couldn't simplify this dependency management a tad bit more. Would the thing I'm proposing below work for you?
Ok, I'll start with the other patch first.
(pressed return too soon)
Actually, my plan was to follow this up with a patch which removes usages of that enumeration from the internal api altogether (basically do a s/GetLLDBPath(ePathTypeXXX/GetXXXPath). That should make the internal api nicer, and provide a clean separation between the internal and public api (thereby taking pressure off of adding new enums to the public api just because we have a new kind of an internal path).
Fix a typo in netbsd code.
Thank you for implementing this. We've had code like this in android studio for a long time, but it's definitely better doing it in lldb instead.
Thu, Jun 14
Wed, Jun 13
Tue, Jun 12
I like the idea of centralizing the framework code as much as possible. However, I am not sure how the dependency management fits into this. More details in inline comments.
The change looks good. The only potentially risky thing is the maxLaunchCount change, but the fact that it is overridable by an env var should mitigate that. It looks like a very weird hack that seems to have been here since 2010. I hope we can remove it altogether at some point, and the requirement for configurations (if any) which require it to explicitly request that behavior seems like good step towards that.
Mon, Jun 11
Hmm.. it looks like most C++ API calls don't have any documentation.
It does look like the python API has more documentation.. where does that come from?
Committed as r334411. I also squeezed in a quick test.
Committed as a part of D47887 via monorepo.
This is a good start, We probably need a test. Pavel: can you outline what Ryan would need to do to add a test for this?
Looks great. Thanks.
Fri, Jun 8
Yea, relying on addresses inside compiler-generated binaries would be extremely brittle. However, line numbers should be fairly stable. Maybe we could have lldb-test take an file+line argument, resolve that into an address, and then look up the relevant symbol context? As a bonus we also get to test line number resolution :P.
Aha I see.
Thank you for your patience. I am very happy with the final result here.
Did you investigate when does this happen? I take it it can happen if a user has a custom std::unique_ptr definition that kinda looks like the libstdc++ one, but not really, but I am wondering if we're not missing something else here..
Thu, Jun 7
Yea, one day I'll have to try that out. I'm just putting it off cause it would nuke all my branches and build folders :/
Thanks for the patch. I have a bunch of comments, but none of them are really serious. Now we just need to figure out the testing...
As a general rule, lld-link is command line compatible with MSVC and
clang-cl is command line compatible with cl. So, the /order option should
work exactly the same with lld-link as it does with link.
It seeems that it is not implemented:
>lld-link /debug /nodefaultlib /entry:main /order:@test-pdb-function-level-linking.ord test-pdb-function-level-linking.obj
C:\LLVM\bin\lld-link.EXE: error: could not open /order:@test-pdb-function-level-linking.ord: no such file or directory
lld-link /? also don't list such option.
looks good to me
Thank you for implementing the lldb-test extension. Now that we have that, and the /order, we should be able to get rid of the binaries for the function-level-linking test. You should be able to rewrite it into something like this:
Btw, would it be possible to use the /order directive to achive what you want? (/order:function_from_first_file,function_from_second_file,another_function_from_first_file)
I don't think that's necessary. The actual fix is really simple and this whole discussion is just about figuring out what to do with tests.
I think these kinds of checks would be a nice fit for a lldb-test symbols --verify option.
Can you explain this in detail, please?