Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add two commands pproperties, pblock #133

Merged
merged 16 commits into from
May 9, 2016

Conversation

longv2go
Copy link
Contributor

@longv2go longv2go commented Jan 3, 2016

pproperties can print the properties of an instance of Class.

(lldb) ppro self
@property (nonatomic, assign, readonly) NSString * helo;
@property (nonatomic, strong) NSNumber * number;

pblock can print the implementation address and signature of a block.

(lldb) pbl block
Imp: 0x101180980    Signature: void ^(NSString *);

@kastiglione
Copy link
Contributor

Thank you. I'm hoping to review this before the end of the week.

@kastiglione kastiglione self-assigned this Feb 5, 2016
@kastiglione
Copy link
Contributor

@longv2go What do you think of looking up the symbol that corresponds to the block's invoke function, using something like image lookup --address or via the equivalent lldb api? Another thought to put out there, what do you think of print the objects that the block captures?

@longv2go
Copy link
Contributor Author

longv2go commented Feb 5, 2016

@kastiglione The pblock just show the invoke function`s address, and I do not know which lldb api can do that. I can go deep with the block struct to find out if I can print the objects that the block captures.

@kastiglione
Copy link
Contributor

I'm also not sure which part of the lldb api we're looking for, but worst case scenario we could call HandleCommand and pass it image lookup --address with the address of the invoke function pointer.

The two suggestions were just for discussion, they actually came up today when I was showing chisel to someone. They asked about inspecting blocks and I remembered this pull request (sorry). If adding symbol lookup isn't much work, which I hope is the case, then I think it's a no brainer to add. However I suspect getting the captured objects is more work and I also don't think it's as valuable as the symbol lookup. Those are my thoughts.

thanks!

tmpString = """
NSMutableArray *result = (id)[NSMutableArray array];
unsigned int count;
objc_property_t *props = (objc_property_t *)class_copyPropertyList((Class)$cls, &count);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

props does not ever get freed.

@longv2go
Copy link
Contributor Author

@kastiglione I remove the "free()" because it would cause evaluateExpressionValue to raise exception some time on real device. I do not know the reason. I guess it`s a lldb bug.

@longv2go
Copy link
Contributor Author

@kastiglione The block struct is dynamically generated by the compiler. The captured objects and other objects the block referenced are all attached to that struct, such as

struct __block_literal_2 {
    void *isa;
    int flags;
    int reserved;
    void (*invoke)(struct __block_literal_2 *);
    struct __block_descriptor_2 *descriptor;
    const int x;
};

The const int x; is an object referenced by block. So every block is different. I did not find a way to list all captured objects at the runtime.

http://clang.llvm.org/docs/Block-ABI-Apple.html#importing-attribute-nsobject-variables

@kastiglione
Copy link
Contributor

Thanks @longv2go. I'll give this another review today or tomorrow.

@kastiglione
Copy link
Contributor

I remove the free() because it would cause evaluateExpressionValue to raise exception some time on real device.

@longv2go Do you have any more details on this? I guess it doesn't matter if a bit of memory leaks in debugging, but if it is an lldb bug, we might want to report it or track it if it's known.

@longv2go
Copy link
Contributor Author

@kastiglione When I add the free(), I get the error message:

error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=257, address=0x188ae089d).
The process has been returned to the state before expression evaluation.
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=257, address=0x188ae089d).
The process has been returned to the state before expression evaluation.
Traceback (most recent call last):
  File "/Users/didi/Workspace/github/chisel/fblldb.py", line 79, in runCommand
    command.run(args, options)
  File "/Users/didi/Workspace/github/chisel/commands/FBClassDump.py", line 84, in run
    printProperties(cls)
  File "/Users/didi/Workspace/github/chisel/commands/FBClassDump.py", line 195, in printProperties
    props = getProperties(cls)
  File "/Users/didi/Workspace/github/chisel/commands/FBClassDump.py", line 336, in getProperties
    return [Property(m) for m in propsJson]
TypeError: 'NoneType' object is not iterable

and the fb.evaluate(command) get a None.

@kastiglione
Copy link
Contributor

Thanks. Would you mind putting that into a gist, and adding a comment with a link where the free go? If you're busy don't worry, we can refer back to this pull request.

@longv2go
Copy link
Contributor Author

@kastiglione I create a new repo. I find a way to print all objects of a block using fishhook. Because the evaluateExpression function can not define a c function, I could`t implement chisel command to print those objects. Please refer https://github.com/longv2go/BlockInspector

@kastiglione
Copy link
Contributor

@longv2go Does your new repo supersede this pull request? Should I still consider merging this, or should people instead use your BlockInspector?

@longv2go
Copy link
Contributor Author

longv2go commented May 5, 2016

@kastiglione the repo BlockInspector is written in Objective-C, It can not implement as a chisel command.

@kastiglione
Copy link
Contributor

@longv2go Understood. Would you like to continue with this pull request? Or do you plan to use BlockInspector instead?

@longv2go
Copy link
Contributor Author

longv2go commented May 5, 2016

@kastiglione continue this pull request.

@kastiglione
Copy link
Contributor

Thanks again!

@kastiglione kastiglione merged commit 0fe1d9c into facebook:master May 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants