Page MenuHomePhabricator
Feed Advanced Search

Thu, Aug 22

jingham accepted D66628: [Symbol] Decouple clang from DeclVendor.

LGTM

Thu, Aug 22, 6:29 PM · Restricted Project, Restricted Project
jingham accepted D66581: [lldb] Construct the dummy target when the first Dummy object is constructed.

You can go a long time without actually using the Dummy target, which is why I made it lazily.

Thu, Aug 22, 10:16 AM · Restricted Project

Mon, Aug 19

jingham added a comment to D66345: [lldb][NFC] Allow for-range iterating over StringList.
Mon, Aug 19, 10:27 AM · Restricted Project

Fri, Aug 16

jingham accepted D66174: [Utility] Reimplement RegularExpression on top of llvm::Regex.

Pavel said "we'll just have to bite the bullet and say that our expressions are now (more or less) POSIX conformant"... We should say this somewhere users are likely to find.

Fri, Aug 16, 1:10 PM · Restricted Project, Restricted Project
jingham added a comment to D66354: Add LLDB dataformatters for llvm::StringRef and lldb_private::ConstString.

I don't think you need to go back and cover all the ones already added, but could we start adding tests for new lldb/llvm data formatters as we add them? That way we can keep them useful as people change llvm.

Fri, Aug 16, 10:04 AM · Restricted Project

Thu, Aug 15

jingham committed rG7049b0ad4d61: Stop-hooks weren't getting called on step-out. Fix that. (authored by jingham).
Stop-hooks weren't getting called on step-out. Fix that.
Thu, Aug 15, 2:39 PM
jingham committed rL369052: Stop-hooks weren't getting called on step-out. Fix that..
Stop-hooks weren't getting called on step-out. Fix that.
Thu, Aug 15, 2:37 PM
jingham closed D66241: stop-hooks don't fire on "step-out".
Thu, Aug 15, 2:37 PM · Restricted Project, Restricted Project
jingham added a comment to D66241: stop-hooks don't fire on "step-out".

Better. Might be good to put a comment inside CalculatePublicStopInfo() regarding why the "SetStopInfo(GetStopInfo());" is needed. Seems like you could just remove the code from the sight of it. I will leave that up to you though.

Thu, Aug 15, 2:20 PM · Restricted Project, Restricted Project

Wed, Aug 14

jingham updated the diff for D66241: stop-hooks don't fire on "step-out".

Does this seem clearer? We use the language of Private and Public StopInfo's in a bunch of places, even though at present that's more about "How" you get them than actual separate entities. But still, this seems like it follows the language we are using elsewhere.

Wed, Aug 14, 4:29 PM · Restricted Project, Restricted Project
jingham added a comment to D66241: stop-hooks don't fire on "step-out".

Do you think I should put more verbiage in the comment, or would this have been clear if you were actually working on the code?

Wed, Aug 14, 3:13 PM · Restricted Project, Restricted Project
jingham added inline comments to D66241: stop-hooks don't fire on "step-out".
Wed, Aug 14, 2:23 PM · Restricted Project, Restricted Project
jingham created D66241: stop-hooks don't fire on "step-out".
Wed, Aug 14, 12:38 PM · Restricted Project, Restricted Project
jingham added a comment to D66174: [Utility] Reimplement RegularExpression on top of llvm::Regex.

I think we need to fix the behavior for "", other than that, this looks fine to me.

Wed, Aug 14, 11:39 AM · Restricted Project, Restricted Project

Tue, Aug 13

jingham added a comment to D65682: Give a little more info when "run_to_x_breakpoint" fails.

Thanks for pointing that out.

Tue, Aug 13, 10:07 AM · Restricted Project
jingham updated the diff for D65682: Give a little more info when "run_to_x_breakpoint" fails.

Fixed the inverted call order.

Tue, Aug 13, 10:07 AM · Restricted Project

Fri, Aug 9

jingham added a comment to D56010: [NativePDB] Fix setting breakpoint by file and line.

It looks like the code changes landed (probably as part of another patch) but not the tests. I'll look and see if the tests should to be revived.

Fri, Aug 9, 3:22 PM

Thu, Aug 8

jingham committed rG8240b0d7fe31: Fix a comment which was incorrect. (authored by jingham).
Fix a comment which was incorrect.
Thu, Aug 8, 1:49 PM
jingham committed rL368340: Fix a comment which was incorrect..
Fix a comment which was incorrect.
Thu, Aug 8, 1:49 PM

Tue, Aug 6

jingham added a comment to D65611: [Driver] Expand the executable path in the target create output.

Given that we do some work to find executables (like search along the path for "ls" -> /bin/ls") which work might not end up with the result you expected, printing the full path seems useful.

Tue, Aug 6, 11:06 AM · Restricted Project, Restricted Project
jingham added inline comments to D65691: Various build fixes for lldb on MinGW.
Tue, Aug 6, 10:10 AM · Restricted Project, Restricted Project
jingham added a comment to D65797: [lldb][CMake] Generating Xcode projects.

Thanks for doing this. Looks okay to me just one typo... But I don't know CMake well enough to comment on substance...

Tue, Aug 6, 10:01 AM · Restricted Project, Restricted Project

Fri, Aug 2

jingham created D65682: Give a little more info when "run_to_x_breakpoint" fails.
Fri, Aug 2, 5:08 PM · Restricted Project
jingham added a comment to D65646: [lldb] Print better diagnostics for user expressions..

That would be fine. In the swift REPL, we increment the line number so that it appears that all the expressions are one contiguous source file. But I think for the expression parser treating each expression as a separate file is a better fiction.

Fri, Aug 2, 1:36 PM · Restricted Project
jingham added a comment to D65646: [lldb] Print better diagnostics for user expressions..

I have a question based on my half-knowledge about the expression evaluator: I thought that we already wrote out a temporary file for the expression in order to support expr -g? Is this orthogonal or do we now have to ways of pretending there is a source file backing up the expression?

Fri, Aug 2, 10:34 AM · Restricted Project
jingham added inline comments to D65555: [lldb] [Process/NetBSD] Enable reporting of new and exited threads [WIP].
Fri, Aug 2, 10:10 AM

Thu, Aug 1

jingham accepted D65489: Format OptionEnumValueElement.

Okay, if clang-format won't undo this, then I'm fine with writing them this way.

Thu, Aug 1, 5:03 PM · Restricted Project, Restricted Project
jingham added a comment to D65611: [Driver] Expand the executable path in the target create output.

IIRC both GetPath and ResolvePath return the number of characters it would take to actually resolve the path. 128 is actually pretty short, so you should check the result and malloc a buffer of the return + 1 if 128 ends up not being enough.

Thu, Aug 1, 3:46 PM · Restricted Project, Restricted Project
jingham added a comment to D65611: [Driver] Expand the executable path in the target create output.

If you just want the path and don't need the FileSpec, you can call the static SBFileSpec::ResolvePath.

Thu, Aug 1, 3:39 PM · Restricted Project, Restricted Project
jingham added a comment to D65489: Format OptionEnumValueElement.

What happens if you clang-format your reformatted version of the setter? Do we need clang-format off for them?

Thu, Aug 1, 3:07 PM · Restricted Project, Restricted Project

Wed, Jul 31

jingham added a comment to D65469: Remove `bugreport` command.

If we don't want to forget that there was specific useful info, we could gate this patch on implementing the "reproducer generate <FEATURE>" feature. That should be easy to add if we're clear this this is the right design for reproducers. But I don't think that "bugreport unwind" was all that much used, so it might be better to design this at leisure.

Wed, Jul 31, 10:32 AM · Restricted Project
jingham added a comment to D65469: Remove `bugreport` command.

The thing the "bugreport unwind" adds is that it runs a handful of commands that gather data useful in diagnosing unwind problems. That's useful when the information you need might not be output by the session in which the bug appeared.

Wed, Jul 31, 10:27 AM · Restricted Project

Mon, Jul 29

jingham added a comment to D65414: Fix ClangASTContext::CreateParameterDeclaration to not call addDecl.

It might be good to see if you can trigger the bug more directly (for instance by getting the SBType for the method and pulling out its arguments?) The reason that a breakpoint triggers this at present is that lldb reads the debug info for the function to find the prologue extents so it can more accurately push the breakpoint past the prologue. But that's not really desirable, it is a lot of work just for setting a breakpoint, and if I ever figure out how not to do that, I will. In which case, this test will no longer test what you think it tests.

Mon, Jul 29, 4:01 PM · Restricted Project
jingham added a comment to D65386: [lldb][NFC] Use an enum instead of chars when handling options [WIP].

It worries me a little bit that we are making it harder and harder to figure out "where does the option for "-t" get stored once this CommandObject's options have been parsed. Can you show the steps I would have to go through to get from "-f" to OptionEnumSettingsSet::Force or whatever.

Mon, Jul 29, 11:39 AM · Restricted Project

Fri, Jul 26

jingham added a comment to D65311: [dotest] Remove multiprocessing.

This seems okay to me. I would also check with Jason. I don't know who coordinates running tests remotely - or even if they can run in parallel now. But that's the one bit I don't understand well enough to say yea or nay on.

Fri, Jul 26, 2:29 PM · Restricted Project, Restricted Project
jingham added a comment to D65122: [Symbol] Use llvm::Expected when getting TypeSystems.

It seems to me part of the goal of Alex's efforts is to make it possible for a given lldb to have or not have support for any particular type system. In some future day they might even be live pluggable, so that which ones get loaded would be a user choice. In that future, it is never an error to not have a given type system. And even if lldb has builtin code to support a given type system, I may not want to pay the cost to construct it. If I'm debugging ObjC code in a program that also supports swift, I might want to tell lldb not to bother with swift types.

Fri, Jul 26, 10:39 AM · Restricted Project
jingham committed rGbe4a78af465a: Document that LLDB_LOG macros use the format_providers. (authored by jingham).
Document that LLDB_LOG macros use the format_providers.
Fri, Jul 26, 10:26 AM
jingham committed rL367132: Document that LLDB_LOG macros use the format_providers..
Document that LLDB_LOG macros use the format_providers.
Fri, Jul 26, 10:25 AM
jingham closed D65293: Document the fact that LLDB_LOG uses llvm::format_providers.
Fri, Jul 26, 10:25 AM · Restricted Project, Restricted Project
jingham added a comment to D65293: Document the fact that LLDB_LOG uses llvm::format_providers.

Yeah, I didn't want to bother with formatting in case there were suggestions on content. I checked in a version that's correctly truncated.

Fri, Jul 26, 10:25 AM · Restricted Project, Restricted Project

Thu, Jul 25

jingham committed rG2b6afdf71046: Mention adding predicates to settings in the projects page. (authored by jingham).
Mention adding predicates to settings in the projects page.
Thu, Jul 25, 2:38 PM
jingham committed rL367059: Mention adding predicates to settings in the projects page..
Mention adding predicates to settings in the projects page.
Thu, Jul 25, 2:38 PM
jingham committed rGd16a034c7cd3: Remove a project that was completed. (authored by jingham).
Remove a project that was completed.
Thu, Jul 25, 2:30 PM
jingham committed rL367057: Remove a project that was completed..
Remove a project that was completed.
Thu, Jul 25, 2:30 PM
jingham added a comment to D65271: Increase testsuite packet-timeout 5secs -> 1min.

There isn't an SB API for "settings set" yet. I've put off doing that because the "settings" subsystem is currently unfinished. In the original design you would be specify qualifiers in the setting hierarchy, like:

Thu, Jul 25, 11:01 AM · Restricted Project, Restricted Project
jingham added inline comments to D65128: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC).
Thu, Jul 25, 10:51 AM · Restricted Project, Restricted Project
jingham created D65293: Document the fact that LLDB_LOG uses llvm::format_providers.
Thu, Jul 25, 10:46 AM · Restricted Project, Restricted Project

Jul 24 2019

jingham added a comment to D65109: [LLDB] Remove the Xcode project.

We discussed this and came to an agreement only a few hours before in the team meeting

After all, LLVM is open-source and has a community. Making preemptive decisions in internal team meetings sounds concerning.

As far as we know, Greg was the only user of the Xcode project outside of Apple, and he gave the thumbs up.

I was a user of the Xcode project before Apple.

I don't think removing it was especially controversial

That's right. And still, it would be appreciated to give folks in other time zones at least a chance to take part. Thks

Jul 24 2019, 10:12 AM · Restricted Project, Restricted Project
jingham accepted D65128: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC).

Sure, this is okay.

Jul 24 2019, 10:05 AM · Restricted Project, Restricted Project
jingham added a comment to D65165: [Symbol] Fix some botched logic in Variable::GetLanguage.

Thanks for responding quickly. LGTM, with one comment..

Jul 24 2019, 10:02 AM · Restricted Project

Jul 23 2019

jingham added a comment to D65152: Fix issues with inferior stdout coming out of order.

I agree with Greg, having one function that can do any of the combinations of stdout & stderr seems more convenient.

Jul 23 2019, 1:59 PM · Restricted Project

Jul 22 2019

jingham requested changes to D65128: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC).

Actually, I don't want this change as is. Some logs - like the expression and step logs - are laid out for readability, and LLDB_LOG automatically adds the file & function which will make them much harder to read.

Jul 22 2019, 6:54 PM · Restricted Project, Restricted Project
jingham added a comment to D65128: [Logging] Replace Log::Printf with LLDB_LOG macro (NFC).

IIUC, LLDB_LOG already adds the file and function. A bunch of these logs are also adding FUNCTION, so that's probably going to come out twice now. You should probably remove the duplicates.

Jul 22 2019, 6:46 PM · Restricted Project, Restricted Project
jingham accepted D64042: [Symbol] Improve Variable::GetLanguage.

Sounds reasonable.

Jul 22 2019, 10:24 AM · Restricted Project

Jul 18 2019

jingham accepted D64964: [API] Remove use of ClangASTContext from SBTarget.

This looks fine to me. Makes it really clear that we need SBTarget::FindFirstTypeForLanguage, etc. But FindFirstType was always a crapshoot anyway...

Jul 18 2019, 5:26 PM · Restricted Project
jingham committed rGdb6cfe1337c0: Remember to sort the Xcode project!!! (authored by jingham).
Remember to sort the Xcode project!!!
Jul 18 2019, 3:28 PM
jingham committed rL366508: Remember to sort the Xcode project!!!.
Remember to sort the Xcode project!!!
Jul 18 2019, 3:28 PM
jingham committed rGfa6199bc5d37: Add an expectedFailure test for type finding. (authored by jingham).
Add an expectedFailure test for type finding.
Jul 18 2019, 3:22 PM
jingham committed rL366507: Add an expectedFailure test for type finding..
Add an expectedFailure test for type finding.
Jul 18 2019, 3:22 PM
jingham committed rGee515d3d03e9: The switch to table-genning command options broke the xcode project. This gets… (authored by jingham).
The switch to table-genning command options broke the xcode project. This gets…
Jul 18 2019, 3:22 PM
jingham committed rL366506: The switch to table-genning command options broke.
The switch to table-genning command options broke
Jul 18 2019, 3:22 PM

Jul 17 2019

jingham added a comment to D64853: Fix CommandInterpreter for _regex-break with options.

This looks good in general. I also have a few nits, and you need to fix (and probably test) the behavior for files with spaces in their names.

Jul 17 2019, 5:29 PM · Restricted Project
jingham added a comment to D64897: Move start-address finding to Target, implement fallback if main executable does not have a start address.

I wonder if we ought to allow target properties (target as an example) that are only for testing, so they don't print when you do settings list, etc. But the we could have some settings like a "target.testing.dont-read-LC_MAIN" and that would make it easy to automate your hand testing. Kind of like the "experimental" decorator, except you have to know they exist to use them...

Jul 17 2019, 5:19 PM · Restricted Project, Restricted Project
jingham added a comment to D64844: [Target] Remove Target::GetScratchClangASTContext.

The nice thing about the way the ObjCLanguageRuntime::Get was that is was only useable where we decided it was legit to use it, in the actual ObjCLanguageRuntime plugin or its direct users. If you want to keep the convenience cast function in a header in Plugins/ExpressionParser/Clang, that would be fine.

Jul 17 2019, 2:57 PM
jingham added a comment to D64844: [Target] Remove Target::GetScratchClangASTContext.

Seems like in most places we're just pulling out basic types or their sizes, which we should certainly be able to do with a TypeSystem.

Jul 17 2019, 12:27 PM
jingham added a comment to D64844: [Target] Remove Target::GetScratchClangASTContext.

I think I understand your goal - a worthy one, BTW... But I think this is an unnecessary step along that path.

Jul 17 2019, 12:14 PM
jingham requested changes to D64844: [Target] Remove Target::GetScratchClangASTContext.

This seems partly wrong to me. The point is that the Target holds keeps scratch AST contexts for all the languages it supports. They are the central repository for the accumulation of effects of expressions evaluated while that target is alive. For instance, all the user defined types and variables go there. The Target also manages its lifecycle. So all the Scratch AST Contexts are properly owned by the target. For instance, in the swift case if there's a module that we can't import, we have to fall back to making an AST Context for each module we can successfully import and dispatching expressions to the appropriate one of those.

Jul 17 2019, 10:23 AM

Jul 12 2019

jingham accepted D63813: Adjust variable formatting table.

That looks good.

Jul 12 2019, 3:59 PM · Restricted Project, Restricted Project
jingham accepted D64670: [lldb][doc] Document how our LLDB table gen initialized options.

Thanks for writing this up!

Jul 12 2019, 3:46 PM · Restricted Project, Restricted Project

Jul 11 2019

jingham accepted D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

That would be cleaner.

Jul 11 2019, 4:21 PM · Restricted Project
jingham added a comment to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

Then the IRDynamicCheck part would go with LLVMUserExpression, and the C-specific checks in Clang...

Jul 11 2019, 4:01 PM · Restricted Project
jingham accepted D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

Okay... Provided we can come up with not too torturous ways to get the ObjC and Swift support out of generic-code, it seems okay to do this as a first step. I just don't want to end up in the state where we have ObjCLanguageRuntime as generic but CPPLanguageRuntime is not.

Jul 11 2019, 4:00 PM · Restricted Project
jingham added a comment to D64591: [Expression] Move IRDynamicChecks to ClangExpressionParser.

This is a little unclear to me. LLVMUserExpression is the class that represents "anything that uses LLVM at its back end." Both the Swift & Clang user expressions are instances of this. Running through IR and inserting little callouts is an LLVMUserExpression type thing. So it seems like this move is in the right direction, but to be really clean needs to represent LLVMUserExpression in the Plugin Hierarchy.

Jul 11 2019, 3:45 PM · Restricted Project
jingham added inline comments to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.
Jul 11 2019, 3:32 PM · Restricted Project
jingham added a comment to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

My model for this was that there was a CPPLanguageRuntime.cpp that contains everything you can implement about the CPP runtime that is independent of any particular implementation of the CPP language runtime, and then a plugin instance (in this case the ItaniumABILanguageRuntime) that contains all the bits that are specific to a particular implementation. Then putting the CPPLanguageRuntime.cpp in Target lets you know that this has to only contain the generic parts of the runtime behavior. That still seems to me a useful distinction.

I think that's fine, but it does not conflict the idea of the generic parts of a cpp language runtime being a plugin also. This way the generic parts of lldb would be truly language agnostic. Then if anything wants to work with a c++ runtime, but it does not care which one, it can use CPPLanguageRuntime. And if you need a very specific runtime, you go for the Itanium thingy.

Jul 11 2019, 3:24 PM · Restricted Project
jingham added a comment to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

What is the indented relationship between CPPLanguage and CPPLanguageRuntime plugins (and generally between any Language and its LanguageRuntime)? Right now you're having the CPPLanguage depend on the CPPLanguageRuntime plugin. There is no reverse dependency, so this may be fine, if that's how we intend things to be. However, it's not clear to me whether that's the right way to organize things. Intuitively, I'd expect the LanguageRuntime to depend on Language, and not the other way around...

Jul 11 2019, 2:48 PM · Restricted Project
jingham requested changes to D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin.

My model for this was that there was a CPPLanguageRuntime.cpp that contains everything you can implement about the CPP runtime that is independent of any particular implementation of the CPP language runtime, and then a plugin instance (in this case the ItaniumABILanguageRuntime) that contains all the bits that are specific to a particular implementation. Then putting the CPPLanguageRuntime.cpp in Target lets you know that this has to only contain the generic parts of the runtime behavior. That still seems to me a useful distinction.

Jul 11 2019, 2:26 PM · Restricted Project

Jul 8 2019

jingham added a comment to D64365: [lldb] Let table gen create command option initializers..

Do you know how you are going to do enum option values?

Jul 8 2019, 4:52 PM · Restricted Project, Restricted Project
jingham added inline comments to D64159: [Core] Generalize ValueObject::MaybeCalculateCompleteType.
Jul 8 2019, 2:54 PM · Restricted Project
jingham added a comment to D64042: [Symbol] Improve Variable::GetLanguage.

Why did you make this a function of Variable, rather than SymbolContextScope?

Jul 8 2019, 2:35 PM · Restricted Project

Jul 3 2019

jingham added inline comments to D64163: Change LaunchThread interface to return an expected..
Jul 3 2019, 4:16 PM · Restricted Project, Restricted Project

Jul 2 2019

jingham committed rG372cee511e27: Fix for r364686 - actually set symbol_is_missing_weak... (authored by jingham).
Fix for r364686 - actually set symbol_is_missing_weak...
Jul 2 2019, 4:41 PM
jingham committed rL364980: Fix for r364686 - actually set symbol_is_missing_weak....
Fix for r364686 - actually set symbol_is_missing_weak...
Jul 2 2019, 4:40 PM

Jul 1 2019

jingham accepted D63853: [Symbol] Add DeclVendor::FindTypes.

LGTM

Jul 1 2019, 5:25 PM · Restricted Project
jingham accepted D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Sure, NP.

Jul 1 2019, 11:30 AM · Restricted Project

Jun 28 2019

jingham committed rGf2128b28cdb7: Get the expression parser to handle missing weak symbols. MachO only for this… (authored by jingham).
Get the expression parser to handle missing weak symbols. MachO only for this…
Jun 28 2019, 2:41 PM
jingham committed rL364686: Get the expression parser to handle missing weak symbols..
Get the expression parser to handle missing weak symbols.
Jun 28 2019, 2:40 PM
jingham closed D63914: Make the expression parser work for missing weak symbols.
Jun 28 2019, 2:40 PM · Restricted Project, Restricted Project
jingham added inline comments to D63914: Make the expression parser work for missing weak symbols.
Jun 28 2019, 2:37 PM · Restricted Project, Restricted Project
jingham updated the diff for D63914: Make the expression parser work for missing weak symbols.

Addressed Greg's comments

Jun 28 2019, 2:34 PM · Restricted Project, Restricted Project
jingham committed rG8864b4360aab: Make sure the thread list is updated before you set the stop reason on a thread. (authored by jingham).
Make sure the thread list is updated before you set the stop reason on a thread.
Jun 28 2019, 10:58 AM
jingham committed rL364666: Make sure the thread list is updated before you set the stop reason.
Make sure the thread list is updated before you set the stop reason
Jun 28 2019, 10:58 AM
jingham closed D62887: Update the thread list before setting stop reasons with an OS plugin.
Jun 28 2019, 10:58 AM · Restricted Project, Restricted Project
jingham added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

This looks good to me. I wonder if the SymbolContextScope -> Language calculation that you do in IsRuntimeSupportValue should really be done in SymbolContextScope? If that's going to be the policy for going from SymbolContextScope, maybe centralize it there?

Jun 28 2019, 10:07 AM · Restricted Project

Jun 27 2019

jingham created D63914: Make the expression parser work for missing weak symbols.
Jun 27 2019, 6:07 PM · Restricted Project, Restricted Project
jingham added inline comments to D62887: Update the thread list before setting stop reasons with an OS plugin.
Jun 27 2019, 6:07 PM · Restricted Project, Restricted Project
jingham updated the diff for D62887: Update the thread list before setting stop reasons with an OS plugin.

Addresses Greg's question about what happens when we load a new OS plugin. Indeed we should limit the work we do only to the case where we didn't have an OS plugin, then tried to load one and succeeded. Only then do we need to clear and update the thread list.

Jun 27 2019, 6:07 PM · Restricted Project, Restricted Project
jingham added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

@jingham: Okay, so I tried to do what you suggested and that solution doesn't work because of ObjC++. After looking into it, it looks like Variable and Function just ask the CompileUnit for the language type instead of determining it themselves meaning that we determining the Variable's language boils down to asking the CompileUnit for its language. That can probably be improved, but I think that just relying on the SymbolContextScope alone isn't yet sufficient. I think it would be worth it to ask the SymbolContextScope before trying all the loaded language runtimes though. Would you be okay with that solution?

Jun 27 2019, 3:09 PM · Restricted Project

Jun 26 2019

jingham added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

To be more precise, "frame" is the wrong word to use, Variables have "scopes"... All Variables have a scope, though not every scope is contained in a Function.

But just to back up a little bit.

We're getting into problems, it seems to me, because we're asking ValueObjects questions that should be asked of their containing scope. For instance, if you are in a Function, and want to list the locals and arguments, you want to know what the rules for the Function are for which artificial variables should and should not be printed, not any of its value objects.

For instance, ObjC could decide that it wants to reserve the word "this" in methods of ObjC classes in ObjC++ files, and use it as a should-be-hidden artificial variable that will always store a pointer to C++ object for some evil purposes. Asking the runtime language of this artificial "this" variable whether the word "this" is runtime whitelisted seems like the wrong thing to do. After all, the Variable has a CompilerType that's clearly a C++ object, so you might reasonably expect its runtime language to be C++. But then you would get the wrong answer. You really need to ask the Function "what are your rules for hiding artificial variables".

Getting to the right actor to ask about "which artificial variables to show" was the reason for suggesting that the runtime language of a Variable should be that of its containing scope. But then you get into the weird situation where a C++ Variable is claiming a runtime language of ObjC++, which seems a little odd. Instead, it makes more sense to get the RuntimeLanguage of the current frame, and then iterate over the variables and ask the frame's runtime whether they should be shown or not.

I'm not sure what to do about global variables. Reasoning by analogy, that's something that the language of the CompileUnit which contains the global variables should answer.

If I understood you correctly, your conclusion is that ValueObject::IsRuntimeSupportValue shouldn't really exist and that you should be asking a frame or a compilation unit if a value should be displayed to the user. I think that this is reasonable. That being said, I think that this idea will have some interesting challenges as well. One problem that I'm aware of at the moment is that SBValue has IsRuntimeSupportValue. If I remember correctly, removing from the SBAPI is generally not permitted (something I disagree with in general, but I digress).

In the short term, I'd like to get this patch (or some variation of it) into LLDB so that we can remove ValueObject's dependence on ObjC (after this there's one reference left but I have a good idea of how to remove it). Would you mind if I committed this, or do you feel strongly that we should first refactor further?

Jun 26 2019, 5:04 PM · Restricted Project
jingham added a comment to D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue.

Shouldn't ValueObjectVariables figure out their runtime language from their defining frame, not their CompilerType? For a ValueObject you get from an expression, you probably can't do that. But we're always talking about hiding locals or args here - i.e. they are all ValueObjectVariables. And it seems to me that in that case getting the RuntimeLanguage from the containing frame is much more useful than from the CompilerType.

Does every variable have an associated frame? I imagine things like global variables wouldn't. I'm not sure if any language or implementation of a language has global variables as compiler/runtime helper variables, but I'm not comfortable making that assumption since one of my goals is more generalized language support.

Jun 26 2019, 4:01 PM · Restricted Project