Page MenuHomePhabricator

jingham (Jim Ingham)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 23 2014, 5:24 PM (277 w, 3 d)

Recent Activity

Thu, Jan 16

jingham added a comment to D72898: [lldb] add to gdb to lldb doc.

There's a copy paste error in the first header. Other than that, this is fine, thanks for adding the entries!

Thu, Jan 16, 7:22 PM · Restricted Project

Wed, Jan 15

jingham added a comment to D71575: [LLDB] Add ObjectFileWasm plugin for WebAssembly debugging.

BTW, I had to fix this patch (cd9e5c32302cd3b34b796683eedb072c6a1cfdc1) to build on macOS. uint64_t and size_t are differently spelled (though I think otherwise equivalent.) One is "long long unsigned int", the other "long unsigned int". I have no idea why that's true, but std::min refuses to compare a size_t and a unit64_t. Anyway, I fixed this by casting one of the two sides of the comparison. But this was causing problems because we have an api (ReadImageData) that takes a uint64_t for the offset and a size_t for the size. That seems a little weird to me, why are these different types?

Wed, Jan 15, 6:24 PM · Restricted Project
jingham committed rGcd9e5c32302c: Fix the macos build after D71575. (authored by jingham).
Fix the macos build after D71575.
Wed, Jan 15, 6:15 PM
jingham added a comment to D72748: [lldb/IOHandler] Change the way we manage IO handler.

So I did a bunch of original IOHandler. And there are many complex cases for sure. One thing to be aware of is that if you won't use editline() and we call fgets() in the default implementation, there is no way to cancel this IIRC. So it might be worth trying this without editline support to make sure things don't deadlock. If the test suite is happy, then this looks worth trying, though with all the complexities I don't think we can guarantee this doesn't cause issues in some unexpected way. The main things that worry me are:

  • REPL issues since the REPL and (lldb) prompt switch between themselves in a tricky way where they swap IOHandlers
  • running from python script directly when no IOHandlers are pushed because no command interpreter is being run and all the fallout from the cases (HandleCommand that results in a python breakpoint callback etc)
  • the process IO handler that does STDIO for a process
  • when no editline, we use fgets() that can't be canceled
Wed, Jan 15, 12:05 PM · Restricted Project

Tue, Jan 14

jingham added inline comments to D72662: dotest.py: Add option to pass extra lldb settings to dotest.
Tue, Jan 14, 11:33 AM · Restricted Project
jingham added a comment to D72684: [lldb][NFC] Rename ClangASTContext to TypeSystemClang.

I agree it should be TypeSystemClang, since that's how we name all the plugins. Other that that this seems like a great change. We should do the same for swift to keep things consistent, though that's not relevant to this patch.

Tue, Jan 14, 11:11 AM · Restricted Project

Thu, Jan 9

jingham added a comment to D72437: [lldb/Bindings] Move bindings into their own subdirectory.

This is a great cleanup. Thanks for doing it.

Thu, Jan 9, 12:16 PM · Restricted Project

Wed, Jan 8

jingham added a comment to D72413: Add missing nullptr checks..

If we can't make a persistent expression state, are we going to be able to do anything useful with expressions? I don't see anything wrong here, but it seems like we should really be putting up a crunchy frog warning and erroring out of "expr"directly if we really can't make a type system.

Wed, Jan 8, 3:09 PM · Restricted Project

Tue, Jan 7

jingham added a comment to D70238: [lldb] Allow loading of minidumps with no process id.

Greg, Jim, any thoughts on pidless processes?

Tue, Jan 7, 10:42 AM · Restricted Project

Mon, Jan 6

jingham added a comment to D71801: [lldb/Lua] Make lldb.debugger et al available to Lua.

+Jim, for his thoughts on debugger+interpreter relationship

I think this is the time to step back and discuss the relationship between debugger and script interpreter contexts...

Mon, Jan 6, 5:20 PM · Restricted Project

Fri, Dec 20

jingham committed rG05b2c6a52cc7: Temporarily restrict the test for D71372 to darwin till we fix it on other… (authored by jingham).
Temporarily restrict the test for D71372 to darwin till we fix it on other…
Fri, Dec 20, 2:39 PM
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

Hey, Mark... The test you added is failing on the Debian bots, e.g.:

Fri, Dec 20, 1:25 PM · Restricted Project
jingham committed rG2a42a5a2f414: In 'thread step-out' command, only insert a breakpoint in executable memory. (authored by jingham).
In 'thread step-out' command, only insert a breakpoint in executable memory.
Fri, Dec 20, 11:12 AM
jingham closed D71372: [lldb] Add additional validation on return address in 'thread step-out'.
Fri, Dec 20, 11:11 AM · Restricted Project
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

I committed this (2a42a5a2f4144cd99812ad0d230480f94a1d1c92) but I forgot to attribute the patch to Mark in the commit message. My apologies!

Fri, Dec 20, 11:11 AM · Restricted Project
jingham committed rG810c3cfa664b: ThreadPlanTracer::TracingStarted can't call virtual methods on Thread. (authored by jingham).
ThreadPlanTracer::TracingStarted can't call virtual methods on Thread.
Fri, Dec 20, 11:01 AM

Thu, Dec 19

jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

This looks fine to me. We should let Greg have a final chance to weigh in and then I'll check it in.

Thu, Dec 19, 1:52 PM · Restricted Project

Dec 16 2019

jingham committed rG9e9c5f0a6346: Explicitly specify -std=c++11 and include <mutex> and <condition_variable>. (authored by jingham).
Explicitly specify -std=c++11 and include <mutex> and <condition_variable>.
Dec 16 2019, 6:17 PM
jingham committed rG434905b97d96: Run all threads when extending a next range over a call. (authored by jingham).
Run all threads when extending a next range over a call.
Dec 16 2019, 5:49 PM
jingham closed D71440: Extending step-over range past calls was causing deadlocks, fix that..
Dec 16 2019, 5:49 PM · Restricted Project
jingham updated the diff for D71440: Extending step-over range past calls was causing deadlocks, fix that..

Changed the test case from locking.c - using pthreads directly - to locking.cpp using std::thread & Co.

Dec 16 2019, 5:49 PM · Restricted Project
jingham added a comment to D71440: Extending step-over range past calls was causing deadlocks, fix that..

This looks like a tricky bug. Thanks for tracking it down.

I have two questions though: :D

  • could you use c++11 locking primitives in the test? pthreads do not work on windows
Dec 16 2019, 12:08 PM · Restricted Project

Dec 12 2019

jingham created D71440: Extending step-over range past calls was causing deadlocks, fix that..
Dec 12 2019, 4:13 PM · Restricted Project
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

I believe it is ok for permissions to succeed as long as they don't return invalid permissions. For any address outside any mapped ranges, we should have zero as the permissions. Looking up address mappings for zero will return

[0x00000000 - 0x100000000) ---

no permisssions are represented as "---". Then you can take the end address and look it up, and continue. So as long as we aren't getting bogus values back, we are good.

Then what does the bool return mean?

If there is no memory map info in the process plug-in at all, then false will be returned.

Dec 12 2019, 2:16 PM · Restricted Project
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

I believe it is ok for permissions to succeed as long as they don't return invalid permissions. For any address outside any mapped ranges, we should have zero as the permissions. Looking up address mappings for zero will return

[0x00000000 - 0x100000000) ---

no permisssions are represented as "---". Then you can take the end address and look it up, and continue. So as long as we aren't getting bogus values back, we are good.

Dec 12 2019, 2:05 PM · Restricted Project
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

Screenshots with new error messages.

(I artificially forced this branch to execute, still unable to make it execute at runtime)

I replaced my 0x22 example with 0x200000000, which is unmapped *and* outside the low 32 bit range. GetLoadAddressPermissions still seems to succeed.

Dec 12 2019, 1:55 PM · Restricted Project
jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

I'm not sure how easy it is to do that here, but it would certainly be nice to include these error messages in the actual error output from the "finish" command so that they are visible even without logging enabled.

Dec 12 2019, 11:00 AM · Restricted Project

Dec 11 2019

jingham added a comment to D71372: [lldb] Add additional validation on return address in 'thread step-out'.

Please do print out the return address in the log. That will be helpful.

Dec 11 2019, 4:12 PM · Restricted Project
jingham added a comment to D71310: RFC: Remove "Validators".

Would you mind adding a mention on the Projects page? This was a neat idea and realistically if it just sits in git, in a few months no one will remember it's there.

Dec 11 2019, 11:00 AM · Restricted Project

Dec 10 2019

jingham added inline comments to D71311: LanguageRuntime: Simplify NSException::GetSummary() output.
Dec 10 2019, 4:18 PM · Restricted Project
jingham added a comment to D71310: RFC: Remove "Validators".

Adrian and I talked about this some more. Apparently the idea was that you have some type Foo and you want to look for some error state in instances of that type (Foo::a + Foo::b < 10). So you add a Type Validator for Foo that does this check, and every time lldb prints a variable of type Foo, it will run the Validator on it, and if it fails validation, then the printer will print an ! at the beginning of the printing, and also there's an SB API to get whether the Value passed the validator.

Dec 10 2019, 4:08 PM · Restricted Project
jingham accepted D71233: Do not cache hardcoded formats in FormatManager.

And check the Accept checkbox...

Dec 10 2019, 2:55 PM · Restricted Project
jingham added a comment to D71233: Do not cache hardcoded formats in FormatManager.

This looks fine to me. So long as there wasn't much strict type-based matching done in the Hardcoded Summary providers, then this shouldn't cause the format matching to get slower.

Dec 10 2019, 2:55 PM · Restricted Project
jingham accepted D64844: [Target] Remove Target::GetScratchClangASTContext.

This looks fine, sorry for leaving it too long in the In tray...

Dec 10 2019, 2:55 PM · Restricted Project
jingham accepted D71289: [FormatManager] Move Language lookup into the obviously non-cached part (NFC).

This seems reasonable.

Dec 10 2019, 12:01 PM · Restricted Project

Dec 9 2019

jingham added a comment to D71236: [FormatManager] GetCandidateLanguages shouldn't know about ValueObject..

I'm assuming you already checked that this isn't used in swift-lldb either? Otherwise this obviously LGTM.

Dec 9 2019, 5:26 PM · Restricted Project
jingham added a comment to D71237: [FormatEntity] Add mangled function name support.

If you make the frame format such that it is easy to pull the mangled & demangled names out of the format output (e.g. #${function.mangled-name}# ???${function.name}) then you could check that the two names are different, and for extra credit you could use "lang c++ demangle" to demangle it and match it against the regular mangled name...

Dec 9 2019, 5:26 PM · Restricted Project
jingham added inline comments to D69820: [Symbol] Add TypeSystem::GetClassName.
Dec 9 2019, 5:16 PM · Restricted Project
jingham added a comment to D69820: [Symbol] Add TypeSystem::GetClassName.

One comment on a part you didn't change, but left a C++ specific track in the generic ValueObject code.

Dec 9 2019, 4:52 PM · Restricted Project
jingham added a comment to D70883: [vscode.py] Make read_packet only return None when EOF.

Fair enough, I haven't seen evidence of this (haven't searched for it) but I imagine IDEs need to ignore this as well otherwise they just barf if they're expecting Content-Length and a wild print appears. The notion of stdout of SBDebugger is the SBCommandReturnObject which doesn't print right away (only when the command finishes executing) and from my previous tests .flush() doesn't help with this. I believe this is the reason why people opt to use print instead in their custom commands. But I don't think it's a reasonable assumption (or api contract) to tell people they can't use print or it breaks lldb-vscode.

I'm going to fix this in lldb-vscode itself to wrap all stdout in a proper DAP console response.

Dec 9 2019, 11:48 AM · Restricted Project

Dec 4 2019

jingham committed rG3151d7af72be: Clear out the python class name in OptionParsingStarted for the… (authored by jingham).
Clear out the python class name in OptionParsingStarted for the…
Dec 4 2019, 5:47 PM

Dec 2 2019

jingham added a comment to D70885: [lldb] Use explicit lldb commands on tests.

I don't think it is wise to use shortened command names like "br" in a test if you aren't testing shortest command string. We don't guarantee that we will keep all currently unique shortened command names unique in perpetuity...

Dec 2 2019, 4:02 PM · Restricted Project
jingham added a comment to D70907: Change Target::FindBreakpointsByName to return Expected<vector>.

In other places, I've used "XList" to mean the container that manages the things contained, and "XCollection" to be a random possibly unrelated collection of items. It doesn't make any sense to have a collection of breakpoints from more than one target, so the collection class could ensure that, whereas a std::vector is just a random assortment. But I'm not sure that adds enough value to warrant adding a collection container here. std::vector is fine.

Dec 2 2019, 2:44 PM · Restricted Project

Nov 21 2019

jingham accepted D69880: [lldb] Fix exception breakpoint not being resolved when set on dummy target.

Ack, sorry about that! This looks fine, thanks for chasing it down.

Nov 21 2019, 4:28 PM · Restricted Project
jingham accepted D70448: [LLDB] Fix wrong argument in CommandObjectThreadStepWithTypeAndScope.

Looks right, thanks for catching this.

Nov 21 2019, 10:41 AM · Restricted Project

Nov 20 2019

jingham added inline comments to D70514: [Docs] Generate the LLDB man page with Sphinx.
Nov 20 2019, 4:43 PM · Restricted Project
jingham added inline comments to D70514: [Docs] Generate the LLDB man page with Sphinx.
Nov 20 2019, 3:57 PM · Restricted Project

Nov 14 2019

jingham accepted D70272: [-gmodules] Let LLDB log a warning if the Clang module hash mismatches..

LGTM

Nov 14 2019, 6:36 PM · Restricted Project
jingham added a comment to D70281: Fix -Wunused-result warnings in LLDB.

There's a PP above each instance of this code explaining why it's okay if we don't get the API lock, since that's a bit of a tricky point. So if you want to add a comment, it would be better to say "see explanation above".

Nov 14 2019, 6:17 PM · Restricted Project

Nov 13 2019

jingham added inline comments to D51830: Add a way to make scripted breakpoints.
Nov 13 2019, 12:23 PM · Restricted Project

Nov 12 2019

jingham added a comment to D70134: dotest: Add a way for the run_to_* helpers to register dylibs.

This is fine.

I wondered a bit about whether it would be generally useful to add the 'dylibs that have to be copied' to the SBLaunchInfo? It has some other platform'y like things. I'm not strongly promoting the idea, just thought I'd float it.

You can currently do this by setting the platform file spec for a SBModule. If that is set, then the target will upload the module to that path. The main executable always goes to the remote working directory if its platform file spec isn't set, but any module can set this manually. The register shared libraries code sets the platform path.

Nov 12 2019, 4:35 PM · Restricted Project
jingham added a comment to D70127: [lldb-vscode] Fix a race in test_extra_launch_commands.

It looks like all the continue routines in lldbvscode_testcase.py use self.vscode.wait_for_stopped() after setting the target going. Would that fix the problem here? Without knowing anything about the protocol VSCode is using, I can't say that's right. But if launch is asynchronous, as it looks like it is, it seems reasonable to test whether wait_for_stopped() also works for launch. Be weird if it didn't...

Nov 12 2019, 11:23 AM · Restricted Project
jingham accepted D70134: dotest: Add a way for the run_to_* helpers to register dylibs.

This is fine.

Nov 12 2019, 11:14 AM · Restricted Project
jingham added a comment to D69704: [lldb] Add IsDebugInfoCompatible method to SBModule to allow checking compatibility between language versions.

I think this is fine.

If, for instance, we decided to use .pcm files as a serialization form for type info you would need the same sort of check for modules backed by these pcm's - since the clang in lldb and the clang building the pcm would have to match. BTW I am NOT suggesting that would be a good idea, and this will probably always be a no-op for anything but Swift.

Hm... If I understand modules correctly (and I admit I know very little about them), I think this actually illustrates the my reservations about this. Assuming we were fetching type info from a pcm file etc., there is no relationship between a module (shared library) and a pcm file... I would imagine a module can reference multiple pcm files, and each one could be theoretically built with a different compiler. That then brings up a question of what does it mean for lldb to be "compatible" with the module as a whole...

Nov 12 2019, 10:55 AM · Restricted Project, Restricted Project

Nov 11 2019

jingham added a comment to D69704: [lldb] Add IsDebugInfoCompatible method to SBModule to allow checking compatibility between language versions.

The part that bothers me here is that this assumes that the entirety of a module (or an least the portion of it written in the same language) uses the same version of the language. Is that true for swift? Because it definitely isn't true for c++, as you can easily mix compile units built with different -std flags (and most of the time it will work). So it's not clear to me how this would work for c/c++, or any other language that offers some kind of a version-independent ABI, thus, enabling one to combine different versions in a single module. Nevertheless, since this is how swift works, it seems reasonable to have some way to access this information. However, it's not clear to me if this is the best way to do that...

Nov 11 2019, 5:41 PM · Restricted Project, Restricted Project
jingham added a comment to D70002: [lldb] Make Target* a Target& in CommandObjectExpression::DoExecute REPL logic.

I don't think either version is right.

Nov 11 2019, 2:56 PM · Restricted Project

Nov 8 2019

jingham added a comment to D69913: Re-enable std::function formatter with fixes to improve non-cached lookup performance.

Why not have the FindFunctions lambda take a FunctionSP? It would be easy to get the Function name out of the function in the lambda, and that would make the function more general (and also match what the Foreach does...

Nov 8 2019, 3:56 PM · Restricted Project
jingham added a comment to D70002: [lldb] Make Target* a Target& in CommandObjectExpression::DoExecute REPL logic.

As long as target.GetREPL (..., true) returns a sensible error for the Dummy target, this is fine. Actually having the dummy target run the REPL seems like a bad idea, since that's a pretty heavy-weight activity and the dummy target is supposed to be just for priming settings for future targets.

Nov 8 2019, 10:53 AM · Restricted Project

Nov 7 2019

jingham committed rGf1539b9db39a: BreakpointDummyOptionGroup was using g_breakpoint_modify_options rather than… (authored by jingham).
BreakpointDummyOptionGroup was using g_breakpoint_modify_options rather than…
Nov 7 2019, 2:27 PM
jingham added a comment to D69425: [lldb] Fix broken -D option for breakpoint set command.

No commit access, so would need some assistance getting this change into the repo.

Nov 7 2019, 2:27 PM · Restricted Project
jingham closed D69425: [lldb] Fix broken -D option for breakpoint set command.
Nov 7 2019, 2:26 PM · Restricted Project

Nov 4 2019

jingham added a comment to D69273: ValueObject: Fix a crash related to children address type computation.

In Swift you have to ask the runtime for most of the layout details of objects so getting a const result object, stepping, then asking it to reevaluate itself would lead to passing the runtime incorrect data and potentially undoing a correct type decision that you had made when you fetched the result on the first stop. That's what it sounded like from Davide's description, but I haven't looked at it more deeply yet.

Nov 4 2019, 9:12 AM · Restricted Project

Nov 1 2019

jingham committed rG81cc5d1c7d3f: Don't assume that __cxa_current_exception_type exists. (authored by jingham).
Don't assume that __cxa_current_exception_type exists.
Nov 1 2019, 5:29 PM
jingham added inline comments to D69738: Fix handling for the clang name mangling extension for block invocations.
Nov 1 2019, 2:43 PM · Restricted Project
jingham accepted D69425: [lldb] Fix broken -D option for breakpoint set command.

LGTM, thanks!

Nov 1 2019, 10:19 AM · Restricted Project

Oct 30 2019

jingham committed rG29d5e275f287: Only ask once if we have no commands. NFC. (authored by jingham).
Only ask once if we have no commands. NFC.
Oct 30 2019, 6:04 PM

Oct 28 2019

jingham committed rG651b5e725ee6: Modernize TestThreadStepOut.py (authored by jingham).
Modernize TestThreadStepOut.py
Oct 28 2019, 5:53 PM
jingham closed D69453: Modernize TestThreadStepOut.py.
Oct 28 2019, 5:53 PM · Restricted Project
jingham added inline comments to D69453: Modernize TestThreadStepOut.py.
Oct 28 2019, 3:52 PM · Restricted Project
jingham updated the diff for D69453: Modernize TestThreadStepOut.py.

Addressed review comments.

Oct 28 2019, 3:50 PM · Restricted Project
jingham added a reviewer for D69453: Modernize TestThreadStepOut.py: aprantl.
Oct 28 2019, 11:57 AM · Restricted Project

Oct 25 2019

jingham created D69453: Modernize TestThreadStepOut.py.
Oct 25 2019, 3:52 PM · Restricted Project
jingham committed rG738af7a6241c: Add the ability to pass extra args to a Python breakpoint callback. (authored by jingham).
Add the ability to pass extra args to a Python breakpoint callback.
Oct 25 2019, 2:11 PM
jingham added a comment to D69425: [lldb] Fix broken -D option for breakpoint set command.

Ack, yes. That's definitely wrong. Could you write a test for this to make sure we don't break it in the future. This should fail if you make one target, set a breakpoint with the -D option, then make a second target and check that it has the breakpoint, so it should be pretty easy to write the test? That way I won't break it again...

Oct 25 2019, 10:53 AM · Restricted Project
jingham accepted D69422: [lldb][Docs] Add extra lldb aliases to gdb->lldb map.
Oct 25 2019, 10:43 AM · Restricted Project
jingham added a comment to D69422: [lldb][Docs] Add extra lldb aliases to gdb->lldb map.

I have no objection to documenting the aliases we have. Having the ability to define shortcuts for common operations was one of the key pieces that allowed the straight command set to be laid out in an orderly fashion, which I think is great for discoverability. It's really hard to do the latter and not have some commands be overly long to type. This gives us the best of both worlds.

Oct 25 2019, 10:43 AM · Restricted Project

Oct 21 2019

jingham added a comment to D69273: ValueObject: Fix a crash related to children address type computation.

Except for the comment comment this looks fine.

Oct 21 2019, 5:20 PM · Restricted Project

Oct 16 2019

jingham added a comment to D68968: [android/process info] Introduce display_name.

As Greg said, iOS (and macOS as well, though less directly) have the notion of bundleID. At present, lldb doesn't directly use/figure out the bundle ID, though it could either from the binary itself or from debugserver, which does have to know that. As far as I know we always also have the path, the bundle ID is inferred from the App package the binary path points to. So that complication should not be present on iOS.

Oct 16 2019, 4:43 PM · Restricted Project
jingham added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 16 2019, 10:46 AM · Restricted Project
jingham added a comment to D69014: [LLDB] bugfix: command script add -f doesn't work for some callables.

IIUC, the only external change in this patch is that before if you implemented your Python command using a class with an __call__ method, it would have to be the signature that took exe_ctx. Since this is now switching off of the number of arguments (less self) you could make an __call__ form that didn't take the extra argument. I certainly want to discourage that, since the form without the exe_ctx will do the wrong thing in some contexts (e.g. if the command is used in breakpoint callbacks or stop-hooks). It looks like that would be easy to prevent, you know that you've found call right above where you check. So I think it would be better to explicitly disallow callforms that don't take the exe_ctx.

Oct 16 2019, 10:28 AM · Restricted Project

Oct 15 2019

jingham added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 15 2019, 11:35 AM · Restricted Project
jingham added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 15 2019, 11:08 AM · Restricted Project
jingham added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 15 2019, 10:58 AM · Restricted Project
jingham added inline comments to D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 15 2019, 10:20 AM · Restricted Project

Oct 14 2019

jingham updated the diff for D68671: Add the ability to pass extra args to a Python breakpoint command function.

Addressed Pavel's comments.

Oct 14 2019, 4:40 PM · Restricted Project

Oct 11 2019

jingham updated the diff for D68671: Add the ability to pass extra args to a Python breakpoint command function.

I added ScriptInterpreter::GetNumArgumentsForCallable, so I can base all the decisions on how to call the function on whether I was passed a function with 3 or 4 arguments. That's cleaner. I also plumbed an error through the callback setting, so I can report an error if you pass me a function with the wrong number of arguments, or provide extra_args when you are passing a function that doesn't take 4 arguments.

Oct 11 2019, 6:41 PM · Restricted Project

Oct 10 2019

jingham added a comment to D68671: Add the ability to pass extra args to a Python breakpoint command function.

Looks good overall. A few questions:

  • should we do a global "s/extra_args/args/" edit in this patch? Not sure what "extra_" is adding? Can we remove?
Oct 10 2019, 6:17 PM · Restricted Project
jingham committed rGb895f778e2d8: Die, TABS, die, die, die, die... (authored by jingham).
Die, TABS, die, die, die, die...
Oct 10 2019, 11:22 AM
jingham committed rL374412: Die, TABS, die, die, die, die....
Die, TABS, die, die, die, die...
Oct 10 2019, 11:22 AM
jingham committed rG47b33dcc0df8: Implement serializing scripted breakpoints and their extra args. (authored by jingham).
Implement serializing scripted breakpoints and their extra args.
Oct 10 2019, 10:44 AM
jingham closed D68750: Implement serialization and deserialization of scripted points.
Oct 10 2019, 10:44 AM · Restricted Project
jingham committed rL374394: Implement serializing scripted breakpoints and their extra args..
Implement serializing scripted breakpoints and their extra args.
Oct 10 2019, 10:43 AM

Oct 9 2019

jingham created D68750: Implement serialization and deserialization of scripted points.
Oct 9 2019, 5:45 PM · Restricted Project
jingham committed rGc0da1282fc03: Revert "[lldb] Calculate relative path for symbol links" (authored by jingham).
Revert "[lldb] Calculate relative path for symbol links"
Oct 9 2019, 1:57 PM
jingham added a reverting change for rG958091c209d0: [lldb] Calculate relative path for symbol links: rGc0da1282fc03: Revert "[lldb] Calculate relative path for symbol links".
Oct 9 2019, 1:57 PM
jingham committed rL374226: Revert "[lldb] Calculate relative path for symbol links".
Revert "[lldb] Calculate relative path for symbol links"
Oct 9 2019, 1:57 PM
jingham added a comment to D68696: [lldb][NFC] Remove strange bool parameter from Searcher::SearchCallback.

I have no memory of adding the 'addr' parameter.

Oct 9 2019, 10:46 AM · Restricted Project
jingham accepted D68696: [lldb][NFC] Remove strange bool parameter from Searcher::SearchCallback.

One of the oddities of the Search -> Search callback stuff is that the Searcher's Filter might be narrower than the level at which the Search Callback wants to be invoked. The former is whatever the user actually wants limit the search to which is really undetermined, whereas the latter is the level that is convenient for implementing the callback, so there's no necessary linkage. That means that every time the callback finds a match, it has to check with the filter to see if the match falls within the filter. This parameter was supposed to be a way for the searcher to tell the callback that it's search scope exactly matched the filter, so the callback didn't need to check.

Oct 9 2019, 10:27 AM · Restricted Project

Oct 8 2019

jingham created D68671: Add the ability to pass extra args to a Python breakpoint command function.
Oct 8 2019, 4:27 PM · Restricted Project
jingham added a comment to D68661: StopInfo/Mach: Delete PPC support.

Yes, I don't think we need to support this anymore.

Oct 8 2019, 1:14 PM · Restricted Project