Re: question for gdb users...

[Matt Rice]

On Thu, Sep 24, 2009 at 12:16 AM, Richard Frith-Macdonald
<richard@tiptree.demon.co.uk> 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.