Break out a libChisel

[kastiglione]

I mentioned this in a recent comment, but I'd like to get more feedback on this idea.

Many of the commands end up marshaling a bunch of expressions back and forth between LLDB's python interpreter and the target app, but this has proven to be slowish at times. For example the manual path pvc is a fair bit slower than the path that uses +[UIViewController _printHierarchy].

I believe there could be a solid usability and maintainability improvement if we divided the architecture into two halves:

1. Code that interacts with LLDB's interfaces.
2. Code that interacts with the app's objects and data.

I think we could bundle a dynamic library and have Chisel load that into the app via target modules addprocess load. This adds some complexity, but the benefits would be faster interaction & feedback with Chisel commands, and also I think this would smooth the path toward adding testing to the project. Plus not having to write objc encoded in python strings is an improvement.

cc @arigrant @mattjgalloway @mmmulani @dstnbrkr @KingOfBrian @kolinkrewinkel

[mmmulani]

this would be pretty interesting and I think useful overall. (My only concern is the increasing complexity in loading the two modules)

it would probably help with getting community involvement as well, as I expect most people are put off by the foreign python way of doing lldb stuff

[mattjgalloway]

I like this idea a lot.

Huge +1 from me.

[kastiglione]

My only concern is the increasing complexity in loading the two modules

Yep, that's my concern too. The good thing is there will be feedback sooner than later when attempting to implement this.

[kastiglione]

help with getting community involvement as well, as I expect most people are put off by the foreign python way of doing lldb stuff

Yep, this too!

[KingOfBrian]

Great idea! Although I had fun figuring out how to use objective-c via python, it wasn't the most productive process.

I don't think the slowness of the commands is that big of a deal, but I bet developers would be more inclined to contribute if it wasn't so painful to develop for.

[kastiglione]

@alloy raised a good (and obvious, yet missed) point on Twitter: this approach will be troublesome on device.

[mmmulani]

for iOS 7 and 8 or is this just a 7 problem?

I wonder if there's some way to hack it in

On 12 Dec 2014, at 18:00, Dave Lee [email protected] wrote:

@alloy raised a good (and obvious) point on Twitter: this approach will be troublesome on device.

—
Reply to this email directly or view it on GitHub.

[kastiglione]

Some experimentation will be required. First hurdle is getting the library from the computer loaded into the process on the device.

[mrtom]

I wonder if Zack L (at FB) would be a good person to speak to about loading onto a device.

[zlandau]

Yeah you'll probably run into a copy issues loading onto a device. lldb in general would make it very easy, but that assumes you can have write+execute pages, so that method is probably out. The next method would be to save the library onto the device and then dlopen it (easiest way is probably have some code on the client side that knows how to download it from an endpoint). Or just always ship it as part of your debugging app.

But you'll have to sign the library with the same key that the main app was signed. The best way to do that is probably have a little script that looks at the key used to sign the main app, and try to sign the library with the same key.

[mmmulani]

sounds like way too much effort for a brittle mechanism that would run on every lldb start up.

could we fake this with lldb expressions and blocks to create the stuff at runtime/first use? (maybe only in the case of on device?)

On 12 Dec 2014, at 23:49, Zachary P. Landau [email protected] wrote:

Yeah you'll probably run into a copy issues loading onto a device. lldb in general would make it very easy, but that assumes you can have write+execute pages, so that method is probably out. The next method would be to save the library onto the device and then dlopen it (easiest way is probably have some code on the client side that knows how to download it from an endpoint). Or just always ship it as part of your debugging app.

But you'll have to sign the library with the same key that the main app was signed. The best way to do that is probably have a little script that looks at the key used to sign the main app, and try to sign the library with the same key.

—
Reply to this email directly or view it on GitHub.

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[kastiglione]

This did happen in #197