My end goal is to modify an Objective-C program's symfile in LLDB. I want to augment the method names so a new, unique name can be used to reference an existing method in the debug symbol file.
For example, if there is a method named -[Foo bar], I can of course break on this method using (lldb) b -[Foo bar], however, I want to create an "alias" for this method named -[Foo baz], so when I execute the following in lldb:
(lldb) b -[Foo baz]
A breakpoint will get set on the address at:
method_getImplementation(class_getInstanceMethod([Foo class], #selector(bar)))
My current method of solving this is to use the dsymutil function to dump the symfile:
dsymutil /path/to/executable -o dump.dYSM
From there, I can use the dwarfdump command to prettify the output into something I can actually edit.
dwarfdump dump.dYSM/Contents/Resources/DWARF/ExecName
Now I can easily edit the AT_name property which contains -[Foo bar]
However, I don't know how to regenerate the dYSM after I have the debug info in this "prettify" format.
Provided I can regenerate the edited dYSM, I am hoping to stick it back into LLDB using either:
(lldb) target modules add or (lldb) target symbol add
So my questions are:
Is there a better way to go about this? Note that I do not have the source nor the object files to regenerate a new dYSM.
Is there a Terminal command that can patch up my edited dwarfdump for me into a LLDB readable debug symbol file?
Cheers!
I'm not entirely clear what you are trying to achieve. It sounded at first like you were trying to break on the dynamically determined implementation of some class/selector pair, in which case you can just do:
(lldb) break set -a `(void *) method_getImplementation((void *)class_getInstanceMethod([Foo class], #selector(bar)))`
Note, you'll have to do this after you've run your program and hit a breakpoint, but then you won't know the specific implementation that's going to get called until you run anyway, so this isn't much of a restriction.
But just munging the name in the DWARF wouldn't have actually achieved this effect. So maybe if you say a little more about your actual aims we can be of more help.
As to question 2, there are no tools to edit dSYM DWARF content after the fact. That's not something there's been much call for.
Related
Ok, so say you were getting an error when compiling such as..
Retain'ed block property does not copy the block - use copy attribute instead
because of...
-Wobjc-noncopy-retain-block-property
to which you could fix the problem, or possibly add a flag such as
-Wno-objc-noncopy-retain-block-property
But let's further suppose you liked to use "Configuration" (.xcconfig) files, and you thought, "OK, since I can use...
CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS = NO
maybe I'll try.."
CLANG_WARN_OBJC_NONCOPY_RETAIN_BLOCK_PROPERTY = NO
Only to discover this does NOT work.
So the question retains, umm remains... What DOES work?
Xcode allows you to copy entries from the Build Settings pane using ⌘-C; the result when pasting is the text that corresponds to that setting for use in an .xcconfig file.
When I entered -Wno-objc-noncopy-retain-block-property into the "Other Warning Flags" row, and copy-pasted that into a new .xcconfig file, I ended up with this:
//:configuration = Debug
WARNING_CFLAGS = -Wno-objc-noncopy-retain-block-property
//:configuration = Release
WARNING_CFLAGS = -Wno-objc-noncopy-retain-block-property
and that does indeed seem to supress the warning about a retain Block property.
I have run into someone else's code that declares methods like this:
- (void) method:(id)a:(NSString*)b { }
The compiler accepts this code, giving just a warning:
'a' used as the name of the previous parameter rather than as part of the selector
The code declares various functions with this type and then invokes them through NSSelectorFromString, using the signature "methodname::". So it's all consistent.
I wonder if that method signature is just a mistake or if there's more to it. Since it's used consistently in the code, I don't think this is a typo. I don't know the author so I can't tell if this is code of a genius or the opposite.
Is 'b' an anonymous parameter? (If so, shouldn't it rather be written with a blank between the "a" and ":" to indicate this better?) I can't find anything about anon parms in the ObjC docs, though.
Will there be any change in behavior if I change the syntax to giving the second parameter a name, and fixing the signature reference accordingly? I plan to make this change to get rid of the warnings, but I wonder I might create an issue that I'm not aware of.
Everything you describe is pretty much correct. It's very bad style, but technically it's just a two-argument selector which happens to have no text before the second :. I wouldn't call b an anonymous argument since you can still give it a name, it just doesn't have any descriptive text before it as part of the selector's name.
Yes, there should probably be a space after the a.
If you want to rename it, you can use Xcode's standard Refactor->Rename functionality and just insert some text before the second :. It will update all the references and you should encounter no problems.
You can use the signature method::, even though it is not recommended by most people.
Just insert a space character before each : separating the parameters, and the compiler is happy:
- (void) method:(id)a :(NSString*)b
On page 16 "Message Syntax" of The Objective-C Programming Language
this is called an "unlabeled argument", or an "argument without keyword".
Of course you can change it to
- (void) method:(id)a withB:(NSString*)b
but this changes the selector to method:withB:.
This is one of my favorite eclipse features. Does it exist in Xcode? I'm getting tired of cutting and pasting from my header files in to my implementations.
Just type "dash" then "space" and start typing the method name that you want to override. Now push Esc.
Example:
- tab
will prompt your to pick a method that overrides any of the TableViewDatasource / Delegate methods. Hit Return and it will automatically provide the return type too...
Here's a pic of what it looks like and notice that I did not provide the return type myself:
Cheers...
This is the kind of task that a user script is useful for. I use this one I banged out in ruby.
#! /usr/bin/env ruby -w
dash="------------------------------------"
r=/(^.+);/ # find entire function definition
pr=/(\w+(:|;))/ #find named parameters to make selector style string
s=STDIN.read
s.each_line() do |l|
m=l.match(r)
if m
n=l.match(/:/)
if n #if the function as one or more parameters
params=l.scan(/(\w+:)/)
puts m.captures[0] + "{\n\n}//"+dash + params.to_s + dash +"\n\n"
else #method has no parameters
puts m.captures[0]+ "{\n\n}//"+dash + m.captures[0] + dash +"\n\n"
end
end
end
To use, select a header method definition, run the script, switch to implementation and paste. This one adds in my preferred method comments boiler plate so you can customized that as you wish.
Check out Accessorizer, it may not be exactly what you're looking for, but it could help in other things that you may like. I haven't used it extensively yet, but I got it as part of one of MobileOrchard's bundle.
Take a look at the ODCompletionDictionary plug-in for Xcode. It allows you to define expandable macros that are configurable with many options. It is an enormous time saver.
With Swift, pressing CTRL+SPACE in the class body will bring up auto-complete for methods. Just start typing the method name.
If you're extending a class, XCode 10 doesn't seem to automatically insert override when necessary.
In my language I can use a class variable in my method when the definition appears below the method. It can also call methods below my method and etc. There are no 'headers'. Take this C# example.
class A
{
public void callMethods() { print(); B b; b.notYetSeen();
public void print() { Console.Write("v = {0}", v); }
int v=9;
}
class B
{
public void notYetSeen() { Console.Write("notYetSeen()\n"); }
}
How should I compile that? what i was thinking is:
pass1: convert everything to an AST
pass2: go through all classes and build a list of define classes/variable/etc
pass3: go through code and check if there's any errors such as undefined variable, wrong use etc and create my output
But it seems like for this to work I have to do pass 1 and 2 for ALL files before doing pass3. Also it feels like a lot of work to do until I find a syntax error (other than the obvious that can be done at parse time such as forgetting to close a brace or writing 0xLETTERS instead of a hex value). My gut says there is some other way.
Note: I am using bison/flex to generate my compiler.
My understanding of languages that handle forward references is that they typically just use the first pass to build a list of valid names. Something along the lines of just putting an entry in a table (without filling out the definition) so you have something to point to later when you do your real pass to generate the definitions.
If you try to actually build full definitions as you go, you would end up having to rescan repatedly, each time saving any references to undefined things until the next pass. Even that would fail if there are circular references.
I would go through on pass one and collect all of your class/method/field names and types, ignoring the method bodies. Then in pass two check the method bodies only.
I don't know that there can be any other way than traversing all the files in the source.
I think that you can get it down to two passes - on the first pass, build the AST and whenever you find a variable name, add it to a list that contains that blocks' symbols (it would probably be useful to add that list to the corresponding scope in the tree). Step two is to linearly traverse the tree and make sure that each symbol used references a symbol in that scope or a scope above it.
My description is oversimplified but the basic answer is -- lookahead requires at least two passes.
The usual approach is to save B as "unknown". It's probably some kind of type (because of the place where you encountered it). So you can just reserve the memory (a pointer) for it even though you have no idea what it really is.
For the method call, you can't do much. In a dynamic language, you'd just save the name of the method somewhere and check whether it exists at runtime. In a static language, you can save it in under "unknown methods" somewhere in your compiler along with the unknown type B. Since method calls eventually translate to a memory address, you can again reserve the memory.
Then, when you encounter B and the method, you can clear up your unknowns. Since you know a bit about them, you can say whether they behave like they should or if the first usage is now a syntax error.
So you don't have to read all files twice but it surely makes things more simple.
Alternatively, you can generate these header files as you encounter the sources and save them somewhere where you can find them again. This way, you can speed up the compilation (since you won't have to consider unchanged files in the next compilation run).
Lastly, if you write a new language, you shouldn't use bison and flex anymore. There are much better tools by now. ANTLR, for example, can produce a parser that can recover after an error, so you can still parse the whole file. Or check this Wikipedia article for more options.
I have a class and I want to change the name of a specific method in run time.
I guess there's a method in the 'Behavior' class that does it. But I just can't find it. any help? [in squeak]
The normal way a user does this is to modify the method source and 'accept it' then delete the old version. So it's not likely that basic Squeak includes a single method to do this, although I could be wrong.
However if you install, for example, OmniBrowser there is a method refactoring called 'rename' and you could inspect and find code to perform this refactoring. It is fairly complex, firstly because the refactorings are done using the command pattern which involves a little redirection to work out, but secondly because this is a fairly complex refactoring which includes modifying the call sites.
What you are suggesting puts HUGE red flags up for me.
What is it you are trying to accomplish with this?
Do you mean you want to change the name of the method you are calling at runtime?
If so, that's easy.
do something like:
|methodName|
methodName := self useMethod1 ifTrue: [#method1 ] ifFalse:[ #method2 ].
self perform: methodName.
You best use a refactoring
r := RenameMethodRefactoring
renameMethod: #foo:foo:
in: Foo
to: #bar:bar:
permutation: (1 to: #foo:foo: numArgs).
r execute.
Avoid voodoo magic in real code when possible.
That being said you can do some very interesting things by manipulating methods dynamically.
For instance the code bricks in Etoys are translated into Smalltalk methods. Other DSL implementations can also benefit from similar metaprogramming tricks.
After experimenting a bit I came up with the following code for renaming unary methods:
renameMethod: oldMethod inClass: class to: newMethod
| oldSelector newSelector source parser |
oldSelector := oldMethod asSymbol.
newSelector := newMethod asSymbol.
oldSelector = newSelector ifTrue: [^self].
"Get method category"
category := (LocatedMethod location: class selector: oldSelector) category.
"Get method source code"
source := class sourceCodeAt: oldSelector.
"Replace selector in method source"
(parser := class parserClass new) parseSelector: source.
source := (newSelector asString), (source allButFirst: parser endOfLastToken).
"Compile modified source"
class compile: source classified: category.
"Remove old selector"
class removeSelector: oldSelector
You could probably find an easier way to do this if you browse through the Squeak code a bit longer than I did.
You can't change a method's name, really, because it doesn't have one.
An object's method dictionary maps Symbols to CompiledMethods. "Change the name of a method" means "move the CompiledMethod value from this key to that key".