Page MenuHomePhabricator
Feed Advanced Search

Yesterday

jingham added a comment to D98370: [lldb] Fix SBValue::Persist() for constant values.

Be careful here. There are really two kinds of persistent variables: "expression results" and variables created in the expression parser. The former are by design constant. The idea is that you can use them to checkpoint the state of a value and refer to it later. You can use their values in expressions, but they aren't supposed to be modifiable. Those are the ones called $NUM.

The ones you make in an expression, like:

(lldb) expr int $myVar = 20

on the other hand are modifiable.

What about the values created via SBValue::Persist() then? They have names like $NUM, but they can be either of the two you mentioned and more (values created via CreateValueFromData or values acquired via FindVariable):

Thu, Apr 22, 5:17 PM · Restricted Project
jingham added a comment to D98370: [lldb] Fix SBValue::Persist() for constant values.

Sure. But but when I was poking around at it a little bit, it seems like the other use cases already work, and the only one that was failing was the case where you call persist on a persistent variable. If that is really true, then maybe we should fix the failing case directly.

Right now Persist() doesn't really work for values created via CreateValueFromData. You can read them, but can't modify:

>>> data = lldb.SBData.CreateDataFromUInt64Array(lldb.process.GetByteOrder(), lldb.process.GetAddressByteSize(), [42])
>>> v = lldb.target.CreateValueFromData('v', data, lldb.target.GetBasicType(lldb.eBasicTypeUnsignedLong))
>>> v.value
'42'
>>> vp = v.Persist()
>>> vp.name
'$3'
>>> lldb.frame.EvaluateExpression('$3').value
'42'
>>> lldb.frame.EvaluateExpression('++$3 + 1').value
>>> lldb.frame.EvaluateExpression('++$3 + 1').error.GetCString()
"error: supposed to interpret, but failed: Interpreter couldn't read from memory\n"

However I realized my patch doesn't completely fixes it either:

>>> data = lldb.SBData.CreateDataFromUInt64Array(lldb.process.GetByteOrder(), lldb.process.GetAddressByteSize(), [42])
>>> v = lldb.target.CreateValueFromData('v', data, lldb.target.GetBasicType(lldb.eBasicTypeUnsignedLong))
>>> vp = v.Persist()
>>> vp.name
'$0'
>>> lldb.frame.EvaluateExpression('$0').value
'42'
>>> lldb.frame.EvaluateExpression('++$0').value
'43'
>>> lldb.frame.EvaluateExpression('++$0').value
'44'
>>> vp.value
'42'

Not sure why? The API is a request: "I made a variable somehow, and I would like you to make it persist so I can use its value later on even if the underlying data has changed." Why do you care whether you get a copy of an already persistent or just a shared value?

You're right, I got confused by something else. I don't care if I get a new name/copy, as long as I can use it by the returned name it's fine. However I want to point out that the current API does generate a new name every time (but the it points to the same data):

>>> x = lldb.frame.FindVariable('x')
>>> x.value
'1'
>>> xp1 = x.Persist()
>>> xp1.name
'$0'
>>> xp2 = x.Persist()
>>> xp2.name
'$1'
>>> lldb.frame.EvaluateExpression('++$0 + ++$1').value
'3'
>>> xp1.value
'3'
>>> xp2.value
'3'
Thu, Apr 22, 12:18 PM · Restricted Project

Wed, Apr 21

jingham added a comment to D100965: [lldb] Refactor argument group by SourceLocationSpec (NFCI).

It seems like most of the places where you use the SourceLocationSpec, you also pass "check_inlines" and "exact". Those seem to me natural parts of a source location search specification class, and including them in the Spec would clean up the API's even further. Not necessary if it gets ugly for some reason, but it would look nicer.

Wed, Apr 21, 10:18 AM · Restricted Project
jingham added a comment to D98370: [lldb] Fix SBValue::Persist() for constant values.

If persisting already persistent variables is indeed the only failure case, then I wonder if it wouldn't be more straightforward to just see if the ValueObject is already a persistent variable and have Persist just return the incoming variable.

Persisting already persistent variables is not the only valid use case, one might also want to persist variables created via SBTarget::CreateValueFromData().

Wed, Apr 21, 10:14 AM · Restricted Project

Fri, Apr 16

jingham added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

Since you just mainly want to run this past the bots again, probably best to just resubmit. You could update the patch here or not at your convenience, but I don't see it would serve any purpose to wait on approval.

Fri, Apr 16, 9:59 AM · Restricted Project, Restricted Project, Restricted Project

Thu, Apr 15

jingham added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I had to revert this change because the test case broke the windows builder. What's the right way to update/mark the test case so that it is only run on appropriate architectures & operating systems?

Thu, Apr 15, 5:46 PM · Restricted Project, Restricted Project, Restricted Project
jingham added a comment to D100384: [lldb/Plugins] Update ScriptedProcess Process Plugin.

A bunch of little comments. I was also curious why you directly set the running private state, but use the async thread to generate the stopped events?

Thu, Apr 15, 12:02 PM · Restricted Project

Tue, Apr 13

jingham added a comment to D98370: [lldb] Fix SBValue::Persist() for constant values.

Sorry for the delay!

Tue, Apr 13, 11:24 AM · Restricted Project

Tue, Apr 6

jingham added a comment to D96715: [lldb] Decouple IsMasterPlan and OkayToDiscard (NFC).

I don't understand how DiscardPlansConsultingMasterPlan in this patch works.

Tue, Apr 6, 12:03 PM · Restricted Project

Mon, Apr 5

jingham added a reverting change for rG602ab188a7e1: Revert "Add support for fetching signed values from tagged pointers.": rGbe0ced03ba9b: Revert "Revert "Add support for fetching signed values from tagged pointers."".
Mon, Apr 5, 6:21 PM
jingham committed rGbe0ced03ba9b: Revert "Revert "Add support for fetching signed values from tagged pointers."" (authored by jingham).
Revert "Revert "Add support for fetching signed values from tagged pointers.""
Mon, Apr 5, 6:21 PM
jingham accepted D99828: Create setting to disable LanguageRuntime provided UnwindPlans.

This seems okay to me. Putting it in the process is right. We do "disable X" in a bunch of other places when enabled is the default, so that seems right. And I don't think there's much benefit to trying to squeeze the description into fewer letters, since you're either cutting & pasting into a script or using completion anyway.

Mon, Apr 5, 10:55 AM · Restricted Project

Thu, Apr 1

jingham committed rG4d9039c8dc2d: Add support for fetching signed values from tagged pointers. (authored by jingham).
Add support for fetching signed values from tagged pointers.
Thu, Apr 1, 10:59 AM
jingham closed D99694: Add support for getting signed ObjC tagged pointer values.
Thu, Apr 1, 10:59 AM · Restricted Project

Wed, Mar 31

jingham requested review of D99694: Add support for getting signed ObjC tagged pointer values.
Wed, Mar 31, 5:19 PM · Restricted Project

Thu, Mar 25

jingham requested changes to D99331: [TESTS] Fix TestInlineStepping with ccac compiler.

Raphael is right. The default values of the target.process.thread.step-avoid-regexp are set such that if lldb finds itself in a function inlined from std:: it will automatically step back out. This test is testing that (among other things). The fact that the test is failing means that something in how your compiler is generating symbols is defeating this. Maybe it's emitting the std:: symbols in such a way that the regexp isn't matching them? Maybe the inline records in the DWARF are confusing lldb somehow?

Thu, Mar 25, 10:45 AM · Restricted Project

Wed, Mar 24

jingham committed rG3fd7d0d281a9: Disable the tests except on Darwin. (authored by jingham).
Disable the tests except on Darwin.
Wed, Mar 24, 12:19 PM
jingham committed rGc8faa8c2669c: Make the stop-on-sharedlibrary-events setting work. (authored by jingham).
Make the stop-on-sharedlibrary-events setting work.
Wed, Mar 24, 11:15 AM

Mar 23 2021

jingham accepted D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This looks good to me.

Mar 23 2021, 10:12 AM · Restricted Project

Mar 22 2021

jingham added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 22 2021, 6:21 PM · Restricted Project
jingham added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 22 2021, 4:17 PM · Restricted Project
jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This seems like the right way to go. I made a couple trivial comment comments.

Mar 22 2021, 4:00 PM · Restricted Project
jingham added a comment to D98822: [lldb] [Process] Watch for fork/vfork notifications.

The gdb model - since gdb only supports one debugee per gdb - is to either follow the fork or follow the parent. It would be more in keeping with lldb's model to make a new target for the child side of the fork, and use that to follow the child. That way you can continue to debug both the parent and the child processes. It doesn't look like you've gotten that far yet, but IMO that's the direction we should be going for lldb.

This is no longer true -- gdb supports multiple inferiors these days (I'm not sure when exactly did it grow that support). The automatic detaching of the fork child can be disabled by the "detach-on-fork" setting, at which point you get two inferiors for each fork.

Michal doesn't appear to be interested in this feature right now, just the ability to follow the child process. I think that's fair, as the two inferior setup would be more complicated. However, I am keeping this scenario in mind and making sure that it's possible to support it in the future. The idea is that at the gdb protocol level we will have the notion of two inferiors (using the same syntax that gdb does), but the only thing that the client (and server, mostly) support is to immediately detach from one of the processes after a fork. Later this could be changed to do something more interesting.

Mar 22 2021, 10:38 AM · Restricted Project

Mar 19 2021

jingham added a reverting change for rG9406d4313881: Make the stop-on-sharedlibrary-events setting work.: rG9d081a7ffe5c: Revert "Make the stop-on-sharedlibrary-events setting work.".
Mar 19 2021, 12:40 PM
jingham committed rG9d081a7ffe5c: Revert "Make the stop-on-sharedlibrary-events setting work." (authored by jingham).
Revert "Make the stop-on-sharedlibrary-events setting work."
Mar 19 2021, 12:40 PM
jingham added a reverting change for rGa8d62fc8ff1c: Skip all the tests for Windows.: rGe8e07b3a5e60: Revert "Skip all the tests for Windows.".
Mar 19 2021, 12:40 PM
jingham added a reverting change for D98914: Make target.process.stop-on-sharedlibrary-events setting work: rG9d081a7ffe5c: Revert "Make the stop-on-sharedlibrary-events setting work.".
Mar 19 2021, 12:40 PM · Restricted Project
jingham committed rGe8e07b3a5e60: Revert "Skip all the tests for Windows." (authored by jingham).
Revert "Skip all the tests for Windows."
Mar 19 2021, 12:40 PM
jingham committed rGa8d62fc8ff1c: Skip all the tests for Windows. (authored by jingham).
Skip all the tests for Windows.
Mar 19 2021, 12:06 PM
jingham added a comment to D98914: Make target.process.stop-on-sharedlibrary-events setting work.

I added a couple more tests for having a breakpoint at the load site before committing.

Mar 19 2021, 12:02 PM · Restricted Project
jingham committed rG9406d4313881: Make the stop-on-sharedlibrary-events setting work. (authored by jingham).
Make the stop-on-sharedlibrary-events setting work.
Mar 19 2021, 12:02 PM
jingham closed D98914: Make target.process.stop-on-sharedlibrary-events setting work.
Mar 19 2021, 12:02 PM · Restricted Project
jingham added a comment to D98822: [lldb] [Process] Watch for fork/vfork notifications.

The gdb model - since gdb only supports one debugee per gdb - is to either follow the fork or follow the parent. It would be more in keeping with lldb's model to make a new target for the child side of the fork, and use that to follow the child. That way you can continue to debug both the parent and the child processes. It doesn't look like you've gotten that far yet, but IMO that's the direction we should be going for lldb.

Mar 19 2021, 10:03 AM · Restricted Project

Mar 18 2021

jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Thanks for doing this! The event version looks pretty clean to me. I think we should go that way. I don't think we should have two ways, that seems confusing and still leaves us calling unknown user code in the middle of symbol updates...

Mar 18 2021, 7:27 PM · Restricted Project
jingham requested review of D98914: Make target.process.stop-on-sharedlibrary-events setting work.
Mar 18 2021, 7:19 PM · Restricted Project
jingham committed rG71c4da83b67a: Don't assume that stepping out of a function will land on the next line. (authored by jingham).
Don't assume that stepping out of a function will land on the next line.
Mar 18 2021, 5:48 PM

Mar 16 2021

jingham added inline comments to D98653: [lldb] Refactor variable paths to support languages with non-pointer "this" (NFC).
Mar 16 2021, 11:42 AM · Restricted Project

Mar 8 2021

jingham added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

I bet gdb uses the debugger's CWD because that's the practice working ON gdb (at least back in the day when I worked on it). You built gdb, cd'ed into the gdb build directory and ran the debugger on it from there. gdb's build also produced a debugging-gdb specific .gdbinit file in the build directory that would also get read in if you did it that way. When using command-line debuggers, running from the build directory is probably a fairly common practice. So there are merits to the cwd way of doing things. These merits fade when using IDE's which generally support debugging more than one thing at a time, so changing the working directory of the IDE makes little sense.

Mar 8 2021, 10:19 AM · Restricted Project, Restricted Project, Restricted Project
jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This way of doing progress is going to look odd in anything that uses multiple debuggers. If I'm reading the code aright, if I have two debuggers, and a target in Debugger A starts doing something that would cause progress traffic, both debuggers will show activity.

that is true, but it is a global module repository that benefits both debuggers. And I very rarely debug two things at the same time, so most of the time for most people this will be beneficial and shouldn't cause too much confusion.

Just one tidbit here. Most users are actually routinely running tens of debuggers at the same time, because tests run in parallel and they have a debugger attached by default. Now if you have a long running operation kick in in your unit tests, you might already have a different kind of issue, but I’d like to avoid a world where the IDE displays spurious and wrong information because of this.

But you wouldn't actually hookup any progress callbacks on any of these debuggers right? You don't make a window for each test, IIRC you are only running it under the debugger so you can report issues by using the debugger. Am I remember this correctly? What happens when a test crashes? If you are running 100 tests in parallel and 10 of them crash, do you open a window for each one that does crash? Or do you manually have to debug the test in order to stop at breakpoints or at a crash?

If we truly need debugger specific task progress, that is a lot more work and we have no great solution. One idea is we could end up having progress items take a SymbolContextScope pointer as an optional parameter that would allow us to grab the module pointer from it and then ask the debugger if any targets contain this module prior to reporting progress. This would be a bit expensive code for a lot of quick progress updates as we would need to iterate over each target and each target's module list and we would still have many system libraries reporting progress to all debuggers when targets contain the same system libraries.

The threading overhead and expense of delivering SBEvents also seems like overkill as threading itself and waiting using a mutex + condition will slow down progress delivery especially if we have a progress that does a bunch of updates. And once we receive the event we will need to make a static function call to extract all progress variables (total, completed, progress_id, baton, etc).

Mar 8 2021, 10:07 AM · Restricted Project

Mar 5 2021

jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I agree that we should avoid SBEvent after thinking about it.

Mar 5 2021, 3:29 PM · Restricted Project
jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This way of doing progress is going to look odd in anything that uses multiple debuggers. If I'm reading the code aright, if I have two debuggers, and a target in Debugger A starts doing something that would cause progress traffic, both debuggers will show activity. Given that the candidate for progress that is most common is down in SymbolFile, it's going to be hard to fix that. You'd have to have some way of marking the API boundary from "where you have a Target" to "where you don't have a Target" and record (maybe with TSD) that this target is using this API on this thread... Then you could use that to send the progress to the right actor.

Mar 5 2021, 2:20 PM · Restricted Project

Mar 4 2021

jingham accepted D97985: [lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC).

Yeah, apparently I got tired of typing Fundamental pretty quickly...

Mar 4 2021, 3:39 PM · Restricted Project

Mar 2 2021

jingham added a comment to D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files..

While next to the binary seems like a better guess than the cwd, it does seem awkward that if the binary & dwo's aren't in the same place, you have to move files to get that heuristic to work, whereas you could just "cd" into wherever the dwo's got dumped to make the cwd version work.

Mar 2 2021, 11:44 AM · Restricted Project, Restricted Project, Restricted Project

Mar 1 2021

jingham added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I haven't thought about the details of this implementation closely yet. How will this handled nested progress bars? For instance, if I'm Indexing (maybe even on multiple threads) and then one of the threads results in a debug symbols fetch request (e.g. dsymForUUID). Is the consumer just supposed to check the string that comes into the progress callback to match the now two simultaneous progress elements?

Mar 1 2021, 6:07 PM · Restricted Project

Feb 24 2021

jingham added a comment to D97249: [lldb] Support debugging utility functions.

I am pretty sure other Unix-es share the code to dlopen images that backs "Process::LoadImage". It is trivial compared to the ObjC ones, but is does have a couple of lines of code, 'cause it tries the dlopen and then if that fails, calls dlerror to fetch the error. That is done with a UtilityFunction because it turns out that's performance sensitive for swift.

Feb 24 2021, 11:11 AM · Restricted Project

Feb 23 2021

jingham accepted D97249: [lldb] Support debugging utility functions.

This will be really handy! The code for UserExpressions ends up doing this same thing (over in ClangExpressionParser::ParseInternal. But given how light-weight creating the file is I'm pretty sure it isn't worth trying to activate that code starting from the UtilityExpression. LGTM.

Feb 23 2021, 9:28 AM · Restricted Project

Feb 22 2021

jingham accepted D97165: [lldb] Add deref support and tests to shared_ptr synthetic.

LGTM at this point.

Feb 22 2021, 5:36 PM · Restricted Project
jingham added a comment to D97165: [lldb] Add deref support and tests to shared_ptr synthetic.

This looks great. It's a little weird to use "SBValue.value" to get a string version of something that's a pointer and then have to do regex compares. It's more direct to use "unsigned" and compare against 0x0.

Feb 22 2021, 12:16 PM · Restricted Project
jingham added a comment to D48177: Suppress SIGSEGV on Android when the program will recover.

Another thing that slightly bugs me about this patch is now we have the Architecture with special purpose code to modify the stop reason, and the Platform ditto. I wonder if it wouldn't be better to have a way to register interest in modifying stop infos, and then let the target & architecture sign up for that. That way the next time somebody else needs to do this we won't have to add more special purpose code to Thread.cpp.

Feb 22 2021, 10:14 AM

Feb 19 2021

jingham added inline comments to D97076: [lldb] Refine ThreadPlan::ShouldAutoContinue.
Feb 19 2021, 5:06 PM · Restricted Project
jingham accepted D97076: [lldb] Refine ThreadPlan::ShouldAutoContinue.
Feb 19 2021, 4:28 PM · Restricted Project
jingham added a comment to D97076: [lldb] Refine ThreadPlan::ShouldAutoContinue.

This seems like a fine improvement. One little nit, I would ask the current plan ShouldAutoContinue before popping it. Popping the plan does call WillPop, so the plan does have a chance to react to being popped, and you don't know what it will do. So to be on the safe side it would be better to ask questions of it as an active plan before you pop it.

Feb 19 2021, 4:28 PM · Restricted Project

Feb 17 2021

jingham accepted D96917: [lldb] Rename {stop,run}_vote to report_{stop,run}_vote (NFC).

Sure, that's clearer.

Feb 17 2021, 5:02 PM · Restricted Project
jingham added inline comments to D96839: Add a callout to the LanguageRuntime to override the normal UnwindPlan used for a frame.
Feb 17 2021, 9:19 AM · Restricted Project

Feb 15 2021

jingham accepted D96687: [lldb] Lower GetRealStopInfo into ThreadPlanCallFunction (NFC).

It does seem odd to peek behind the back of a thread plan to figure out how to proceed, so making this special to the UserExpression thread plans, which are special in a bunch of ways, isn't a bad idea.

Feb 15 2021, 2:28 PM · Restricted Project
jingham accepted D96666: [lldb] Remove unused ThreadPlan tracer utilities (NFC).

At some point I had the idea that there would be a whole plugin architecture where you could add observers on all the stops & steps the lldb's execution control did. But for lldb command line & SB API usages, the scripted thread plans add a more natural way to do this. We probably shouldn't take the tracers out altogether. I used them a couple of times (though admittedly pretty far back in the day) for debugging stepping issues. But we don't need the higher level bindings.

Feb 15 2021, 2:21 PM · Restricted Project
jingham accepted D96688: [lldb] Minor refinements to ThreadPlan::RestoreThreadState (NFC).

It is possible that the stub could fail to restore the checkpointed state, though apparently it either never has or never has mattered because no one if setting or checking the bool return. If this does end up failing we should plumb a Status through, since bool is too low information to be useful. This is fine for now.

Feb 15 2021, 2:16 PM · Restricted Project

Feb 11 2021

jingham accepted D96539: [lldb] Add step target to ThreadPlanStepInRange constructor.

I must have thought there would be a case where you wouldn't be able to figure out the target right when you made the plan, but since that possibility never arose, this simplification is fine.

Feb 11 2021, 2:24 PM · Restricted Project
jingham requested changes to D96497: [lldb] Rewrite the 'settings set' command parser.

One confusion that could arise, however, is that since this is a CommandObjectRaw command, we print this at the end of the help:

Feb 11 2021, 11:58 AM
jingham accepted D96497: [lldb] Rewrite the 'settings set' command parser.

LGTM, a few trivial comment comments.

Feb 11 2021, 11:48 AM

Feb 9 2021

jingham committed rG483ec136da71: Use internal_dict everywhere we refer to the python session dict in docs. (authored by jingham).
Use internal_dict everywhere we refer to the python session dict in docs.
Feb 9 2021, 5:49 PM
jingham added inline comments to D96368: Document the "extra_args" parameter to scripted breakpoint callbacks.
Feb 9 2021, 5:49 PM · Restricted Project
jingham committed rGffd7be65d0ef: Remove trailing spaces after \ in comments. (authored by jingham).
Remove trailing spaces after \ in comments.
Feb 9 2021, 4:08 PM
jingham committed rG365b186c242b: Add documentation for the extra_args parameter to breakpoint commands. (authored by jingham).
Add documentation for the extra_args parameter to breakpoint commands.
Feb 9 2021, 3:34 PM
jingham closed D96368: Document the "extra_args" parameter to scripted breakpoint callbacks.
Feb 9 2021, 3:33 PM · Restricted Project
jingham requested changes to D96370: Pass enviroment variables to python scripts..

Modifying the target environment in order to add something to the host lldb's PYTHONPATH seems very counterintuitive to me. It is misusing the purpose of the target environment setting. And it could cause confusion if you set this up (say in your .lldbinit) and then months later wondered why some Python program you were debugging ended up finding python modules in weird places... If you want to have a way to add to lldb's python interpreter's path when starting lldb, then there should be a setting for that specific purpose.

Feb 9 2021, 3:29 PM · Restricted Project
jingham requested review of D96368: Document the "extra_args" parameter to scripted breakpoint callbacks.
Feb 9 2021, 2:03 PM · Restricted Project

Feb 8 2021

jingham added a comment to D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC).

It still seems to me like a trampoline which knew that to implement itself, all it had to do was a couple of stepi's - for instance if a dyld stub knew that the stub had been filled in and would jump straight to the target, it could run without letting the other threads go. That's actually something the dyld stubs could figure out, they just don't at present. So I'd rather not remove this control.

Happy to restore the stop_others parameter, but for my understanding I have two questions:

  1. Is the behavior you envision something that applies to these specific thread plan subclasses (ie not dyld stubs)
  2. Will callers decide to stop others from the outside, or is the decision to stop others something that these subclasses would make internally?
Feb 8 2021, 1:41 PM · Restricted Project
jingham added a comment to D96277: [lldb] Minor cleanups to ThreadPlan.h (NFC).

This is okay. It seems like CachePlanExplainsStop wasn't used because it's done by hand instead. A better patch might be to stop doing that and use the function instead? But the argument's not terribly compelling either way...

Feb 8 2021, 10:59 AM · Restricted Project
jingham added a comment to D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC).

I can't think of a really good reason why you would need to override the general "step in avoids nodebug" behavior. I'm pretty sure I was thinking of a trampoline that got you half way to somewhere interesting, at which point you would want to negotiate again for the trampoline to take you the rest of the way. In that case you would not want to obey the general setting. But this setting controls what happens when you don't find a good place to go, so that control isn't necessary.

Feb 8 2021, 9:56 AM · Restricted Project

Feb 1 2021

jingham added a comment to D95710: [lldb/Commands] Add command options for ScriptedProcess to ProcessLaunch.

I'm not quite sure why we need the extra m_scripted_process boolean. Seems like you could key off whether we had a non-empty class_name. Is there any case where you would want to boolean set w/o having a class name yet?

Feb 1 2021, 6:24 PM · Restricted Project
jingham added a comment to D95761: [lldb] Use current execution context in SBDebugger.

I think it's fine to fall back to the "currently selected target" if the command interpreter doesn't have a current execution context, that should not be your first choice.

Feb 1 2021, 9:48 AM · Restricted Project

Jan 26 2021

jingham committed rG7636b1f6efd5: Make SBDebugger::CreateTargetWithFileAndArch work with lldb::LLDB_DEFAULT_ARCH (authored by jingham).
Make SBDebugger::CreateTargetWithFileAndArch work with lldb::LLDB_DEFAULT_ARCH
Jan 26 2021, 12:19 PM

Jan 25 2021

jingham accepted D95411: [lldb] Remove unused ThreadPlanStack::GetStackOfKind (NFC).

The inverse change to this would be to have all the places where we ask questions about the PlanStacks in a ThreadPlanStack through this API. I put it in to add that abstraction layer, but I don't remember why I thought it might be useful, and I never found any actual motivation for it. So this can go.

Jan 25 2021, 5:37 PM · Restricted Project
jingham committed rG1fba21778f84: Follow on to: f05dc40c31d1883b46b8bb60547087db2f4c03e3 (authored by jingham).
Follow on to: f05dc40c31d1883b46b8bb60547087db2f4c03e3
Jan 25 2021, 2:26 PM
jingham committed rGf05dc40c31d1: Fix SBDebugger::CreateTargetWithFileAndArch to accept LLDB_ARCH_DEFAULT. (authored by jingham).
Fix SBDebugger::CreateTargetWithFileAndArch to accept LLDB_ARCH_DEFAULT.
Jan 25 2021, 12:54 PM
jingham closed D95164: Make SBDebugger::CreateTargetWithFileAndArch accept lldb.LLDB_DEFAULT_ARCH.
Jan 25 2021, 12:54 PM · Restricted Project
jingham added a comment to D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms.

lldb creates a single line table out of the debug_line input and the inlined_subroutine info from the debug_info. For instance, if you have a nested set of inlines that all have the same start address, they cannot be represented in the debug_line which requires monotonically increasing addresses. But when you are "stepping" into the set of nested inlines, lldb would like to represent the step as first stopping before the call in the outer function, then stepping one by one into the nested inlines. I don't know why exactly DWARF line tables need to be monotonically increasing in address, but we couldn't see any good reason why lldb should also have to do this little two-step every time we tried to figure out where you are, we decided to merge the info up front.

Jan 25 2021, 10:40 AM · Restricted Project

Jan 22 2021

jingham accepted D93874: [process] fix exec support on Linux.

Yes, this is how I should have done it originally. Thanks!

Jan 22 2021, 3:33 PM · Restricted Project
jingham updated subscribers of D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms.

If you are just loading an object file and the looking at the line table or something like that, would a UnitTest be more suitable?

Jan 22 2021, 9:42 AM · Restricted Project
jingham added a comment to D93874: [process] fix exec support on Linux.

Excellent, thanks for persisting on this!

Jan 22 2021, 9:39 AM · Restricted Project

Jan 21 2021

jingham added a comment to D93874: [process] fix exec support on Linux.

The ThreadPlanStack always has one base thread plan. You can't get rid of that one, the system relies on its always being there. Despite it's name, DiscardThreadPlans doesn't actually discard all the thread plans, just all but the base thread plan... So I think that's neither here nor there...

Jan 21 2021, 6:04 PM · Restricted Project
jingham added a comment to D95164: Make SBDebugger::CreateTargetWithFileAndArch accept lldb.LLDB_DEFAULT_ARCH.

I think the only difference is the triple is supposed to be a complete triple and the arch can be just "arm64" and like you added, we let the currently selected platform help fill it out? I don't remember why this was added. Nothing in the source history?

Jan 21 2021, 2:56 PM · Restricted Project
jingham requested review of D95164: Make SBDebugger::CreateTargetWithFileAndArch accept lldb.LLDB_DEFAULT_ARCH.
Jan 21 2021, 12:41 PM · Restricted Project

Jan 20 2021

jingham committed rG98feb08e449f: Use CXX_SOURCES and point to the right source file. (authored by jingham).
Use CXX_SOURCES and point to the right source file.
Jan 20 2021, 6:40 PM
jingham committed rGbff389120fa2: Fix a bug with setting breakpoints on C++11 inline initialization statements. (authored by jingham).
Fix a bug with setting breakpoints on C++11 inline initialization statements.
Jan 20 2021, 6:00 PM
jingham closed D94846: Allow breakpoints to be set on C++11 inline initializers.
Jan 20 2021, 6:00 PM · Restricted Project
jingham added a comment to D95100: [lldb/Commands] Fix short option collision for `process launch`.

We shouldn't lightly change options that are commonly used. But we haven't made a strong statement about this the way we do for API. I'm more concerned about people having to rewrite/build and distribute their code to accommodate a new lldb than having to learn a new character for a not very commonly used option.

Jan 20 2021, 5:15 PM · Restricted Project

Jan 15 2021

jingham added a comment to D94846: Allow breakpoints to be set on C++11 inline initializers.

If you set a breakpoint on source lines with no line table entries, lldb slides the actual match forward to the nearest line table entry to the given line number. That's necessary for instance because if you lay out your function definitions over multiple lines they won't all get line table entries, but we don't want people to have to guess which of them was... Same is true of more complicated compound statements.

Jan 15 2021, 6:22 PM · Restricted Project
jingham requested review of D94846: Allow breakpoints to be set on C++11 inline initializers.
Jan 15 2021, 4:47 PM · Restricted Project

Jan 14 2021

jingham updated subscribers of D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms.

How were you setting the breakpoint in the case where it was failing from the command line? The breakpoint you are examining in the test in your patches is a "source regular expression" breakpoint. That would be "break set -p". If you were also doing that in the command line and got a different result that would be very odd, since neither interface (CLI or SB) does much work before handing the request off to the common routine. If (as I suspect) you were doing "b main.c:40" in the command line, then you should make a breakpoint with SBTarget.BreakpointCreateByLocation and see if that shows the same problem. That should do the same job as "break set --file --line".

Jan 14 2021, 2:56 PM · Restricted Project

Jan 12 2021

jingham updated subscribers of D93874: [process] fix exec support on Linux.

Thanks for looking into this further! The thing to figure out is who still has a reference to either the Thread * or to the ThreadPlanStack over the destruction of the thread. That shouldn't be allowed to happen.

Jan 12 2021, 9:47 AM · Restricted Project

Jan 11 2021

jingham added inline comments to D93874: [process] fix exec support on Linux.
Jan 11 2021, 3:52 PM · Restricted Project
jingham added inline comments to D93874: [process] fix exec support on Linux.
Jan 11 2021, 3:27 PM · Restricted Project

Jan 8 2021

jingham added a comment to D93895: Implement vAttachWait in lldb-server.

looks good to me too. When you get around to the wait times & intervals I'd argue for not doing that as a GDBRemote specific addition, as Greg was suggesting above. There's nothing gdb-remote specific about how long you want the debug agent to wait around for some process to show up.

As long as we are find passing these arguments to _any_ process subclass I am find doing these as options.

Jan 8 2021, 10:07 PM · Restricted Project
jingham added a comment to D93895: Implement vAttachWait in lldb-server.

looks good to me too. When you get around to the wait times & intervals I'd argue for not doing that as a GDBRemote specific addition, as Greg was suggesting above. There's nothing gdb-remote specific about how long you want the debug agent to wait around for some process to show up.

Jan 8 2021, 5:09 PM · Restricted Project
jingham added a comment to D94077: Support unscoped enumeration members in the expression evaluator..

We can have unscoped enums in namespace and class scope and the enumerators won't leak out from those scopes. Thus we can have shadowing going on e.g.:

...

How does this change deal with those cases?

Thanks for pointing this out! My first patch didn't really take this into account, so it didn't work properly. I've made some changes to make it work, although I'm not very familiar with these parts of LLDB yet, so I'm not sure whether this approach is how it should be implemented.

Also I've noticed that LLDB's expression evaluator is not perfect with these lookups, e.g. it can find global variables from other scopes if there's no better candidate (not sure if this is a bug of a feature):

Process 3768045 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000401116 a.out`main at global.cpp:2:13
   1    namespace Foo { int x = 1; }
-> 2    int main() {};
(lldb) p x
(int) $0 = 1
Jan 8 2021, 12:26 PM · Restricted Project

Dec 18 2020

jingham accepted D93479: [lldb] Simplify the is_finalized logic in process and make it thread safe..

LGTM. It looks like we never made use of the distinction between "started to finalize" and "done finalizing", so just marking it at the start of finalization seems fine.

Dec 18 2020, 5:58 PM · Restricted Project

Dec 11 2020

jingham accepted D93052: "target create" shouldn't save target if the command failed.

LGTM, thanks for the cleanup.

Dec 11 2020, 10:33 AM · Restricted Project
jingham accepted D92164: Make CommandInterpreter's execution context the same as debugger's one..

LGTM - thanks for doing this!

Dec 11 2020, 10:32 AM · Restricted Project