On Thu, Sep 24, 2009 at 12:16 AM, Richard Frith-Macdonald <[email protected]> wrote: > > On 24 Sep 2009, at 04:40, Matt Rice wrote: > >> there is some discussion here about removing the convenience mechanism >> that allows >> you to go >> >> break foo >> where foo then turns into -[class foo] >> >> this causes lots of issues which are fairly hard to fix in gdb, >> which is why the whole 'break main' with recent gdb causes issues. because >> of >> [NSThread main]. >> >> if you guys opposed to it please let me know and I will relay it into >> the gdb thread, >> I for one wasn't even aware of this feature until it started causing >> problems >> >> http://sourceware.org/ml/gdb-patches/2009-09/msg00734.html >> here is the thread. > > I use this feature tens of times a day, perhaps more ... it's actually > almost the only way I set breakpoints (though I occasionally set breakpoints > at particular lines or in C functions). > > Now, it's not obvious, from a quick read of the thread, why there is a > specific problem with objc ... though it seems to imply that objc is a > special case and this feature is fine in C++ and desired in pascal and ada.
The specific problem is that gdb resets breakpoints upon shared library load, in case symbols were overriden by c-linkage behaviour the 'canonical' version of 'main' is 'main', where the canonical version of '-[NSThread main]' when gdb resets the breakpoint on shared library load to check for a new address for 'main'. it will respond with more than one address, because main is ambiguous, so its unable to tell which of the symbols you actually want a breakpoint on. now imagine if the function was named init :) c++ doesn't suffer from this problem, because they don't do this, break bar will set a breakpoint on a function bar regardless of the existance of a method Foo::bar(void) most languages won't have this issue simply because they don't have their function calling/method dispatch syntax split, calling a foo function or method uses the same syntax. ObjC is different. > I don't mind using the 'break [class method]' syntax where I know that the > implementation of the method is in one particular class, but *usually* I > don't know which class I want to break in (because I'm not aware of all the > libraries/subclasses that might be involved). > > If the underlying problem is one of confusion between objc methods and C > functions (the example of the confusion between the main() function and the > [NSThread-main] method suggests that this may be the case) then perhaps it > could be resolved using a modification of the square brackets syntax ... > > at present we have: this is also a problem with category methods now, i'll work on fixing it but its not going to make the release, until then you can specify the category explicitly. by break -[Foo(bar) method] because -[Foo method] may expand to both -[Foo(bar) method] and -[Foo method]... this is only the case for overridden methods with breakpoints on them though. > +[class method] a factory method of a specific class > -[class method] in instance method in a particular class > [class method] either a factory method or an instance method, with an > option to choose if both exist > > and could add: > > +[method] a factory method of any class > -[method] in instance method in any class > [method] either a factory method or an instance method, these are good ideas, I was thinking +method/-method and was kind of perplexed on what to do for both, [method] might work, i was also thinking ?method, which has no real objc relation, but might be familiar to those using the shell? > So 'break [method] would be like the current 'break method' syntax but > 'method' would be treated *only* as an ObjC method name, never as a function > or method in another language. > > If this would help resolve the issue, it would satisfy me. Simply losing > the ability to set a breakpoint in any class would not. you could still do this with the rbreak command, by using 'rbreak .*methodname.* so even if we remove the function and we don't reintroduce an alternative syntax this is still possible. _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
