- User Since
- Sep 23 2014, 5:24 PM (242 w, 4 d)
Wed, May 15
Tue, May 14
Getting it from the Process's m_language_runtimes is probably fine. On reflection, I can't think of a reason why you would want to iterate over all the available LanguageRuntimes, including the ones that hadn't been recognized in this Process yet.
There is a TypeSystemEnumerateSupportedLanguages that we use so that we don't have to enumerate over all the language in the languages enums. After all the plugin manager knows which languages we have type systems for. If you're going to be doing a lot of this generalization, can you add a similar enumeration for the LanguageRuntimes? There are 40 or so languages in the language enum but we only have a couple of LanguageRuntimes...
Mon, May 13
Excellent, thanks! Can you check this in or do you need me to?
Fri, May 10
With appropriate comments, this seems fine.
I really don't want to pollute the lldb driver options with gdb equivalents (or really any duplicate spellings of already present functionality). For the lldb command line, I want us to have the freedom to do the best job of making the lldb options consistent and easy to document, understand and use, and adding in random duplicate options from gdb will only make this harder.
If you really are going to support many languages you need to figure out how to tell folks what really happened with more specificity. For instance, you can use C++ to throw anything, so you could throw an ObjC object from a C++ exception throw. So you need to distinguish between the language of the exception thrown (which is captured by the ValueObject you return) and the language runtime throwing the language. So we need a way to query that. Also, there's no formula reason why you couldn't have two languages throwing an exception at the same time (for instance if a C++ exception is unwinding the stack and the destructor of some ObjC object that is getting destroyed throws an NSException, etc... So there needs to be some way to handle that.
Thu, May 9
The one outstanding bit of work here is that this change requires that the MSInst "IsCall" function has to mean "will return to the next instruction after call" or we might lose control of the program. It seems obvious that that SHOULD be what it means, but we need to make sure that is always going to be what it means or we risk losing control of the program. Greg is going to follow up on that.
I would rather not clutter up the lldb command driver's options with gdb command flags. That seems like it will make lldb harder to figure out and reduce our freedom to choose reasonable short names for lldb driver options.
That looks fine, thanks for untangling this.
Wed, May 8
Tue, May 7
I wonder if it would make this a little more convenient if we added a SetNoisy as the opposite of SetSilent?
Mon, May 6
The www was the original version, which Jonas replaced with with the rst version. We were waiting to get rid of the www version till we were sure we could iron out all the wrinkles of generating the docs on lldb.llvm.org from the rst version. That's close, though we still don't have the API docs working yet.
LGTM, thanks for doing this and for the test! Can I ask you to write a doc string showing how to call this and what it returns in Python. It's not entirely obvious. There are %feature("docstring" examples around in that file that you can copy from.
Fri, May 3
LGTM, you should probably wait on Pavel's okay to the testing framework changes since that's more his baby...
IIUC, when Expected returns fails, it returns an Error object that might have information about what went wrong. Would it be possible to include the contents of that error n the log message? We often get "I can't run an expression in a really complex proprietary code base" and need to try to sort out what went wrong from these logs. So every crumb of information we can preserve is useful...
Thu, May 2
This makes sense to me. Pinning the extension to the call site prevented all the cases I could think of where this might go wrong.
Could you add a comment (probably best in LanguageRuntime.h) saying what a RuntimeSupportValue is?
Wed, May 1
Fri, Apr 26
That looks nicer!
Oops, forgot to do the action part of this...
Looks good to me too. The fact that you were mostly eliminating redirections from CommandInterpreter -> Debugger is good evidence this was wrongly structured initially.
Thu, Apr 25
I really thought there was one at the SB layer, because in terms of design that is what makes sense. I guess we never really needed it until now, so we didn't add it. Once there's more than one hard-coded script interpreter, we will need to add some way to select & direct scripts at the various script interpreters so we will need SBScriptInterpreter at the SB layer. So maybe now is the time to add it in preparation...
I'm a bit confused. If we get to the world where we can support multiple script interpreters, I would expect to add a static method on ScriptInterpreter that enumerates the available interpreters. I would not expect that to be on SBHostOS since this is not a feature of the Host OS but of how lldb was configured. An lldb running on macOS with the Python2 plugin available behaves - w.r.t. macOS - exactly the same as one built with a Python3 plugin available, etc.
Wed, Apr 24
Yeah, I must have not been paying attention at some point in the past. OTOH, I don't know if you can change the access to the ScriptInterpreter in the SB API's, since that seems likely to break people's scripts.
It seems weird to be getting the ScriptInterpreter's ScriptModuleDirectory from the CommandInterpreter. I would have expected:
BTW, congrats on getting rid of all the LLDB_DISABLE_PYTHON uses. That was a goodly chunk of work and removed an obvious wart.
I agree with Greg, I really don't want to lose the "lldb -P" functionality. That's quite handy.
This seems like an okay workaround.
Tue, Apr 23
Since this just changes how we fix up comments for the generated functions in lldb.py, I can't see any harm in removing it. It is clearly showing you a C-view of the function, so char -> str doesn't seem terribly helpful to me.
Apr 19 2019
Apr 17 2019
Apr 16 2019
One picky comment about the test, otherwise this looks good to me. Pavel had his hands in this code most recently, however, so we should wait on his opinion.
Apr 9 2019
Apr 8 2019
Apr 5 2019
Mar 29 2019
Mar 28 2019
Use yaml2obj to create the dylib with version 0.0.0
Mar 27 2019
Mar 26 2019
It isn't safe to pass "data()" of a StringRef to dlsym.
Mar 25 2019
Except for a typo and a little quibble about a comment, this looks okay to me.
Mar 22 2019
The behavior when verify is false seems a little weird to me. In that case you will just always get the $install_dir/lib/clang/$clang_version path. That's fairly different from the verify = true case. OTOH, I couldn't see anybody passing verify = false anywhere. Do we need that?
Mar 13 2019
Also naming quibble...
I think you have to protect against your dyn_cast failing.
Mar 12 2019
Mar 11 2019
It's a little weird that the CommandObjectExpression is telling the REPL what its options should be, it would be more natural to go the other way. Maybe have the repl_sp provide a properly set up set of EvaluateExpressionOptions and then copy them over to this CommandObjectExpression execution?