[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question for gdb users...

From: Richard Frith-Macdonald
Subject: Re: question for gdb users...
Date: Thu, 24 Sep 2009 09:41:03 +0100

On 24 Sep 2009, at 08:50, Matt Rice wrote:

On Thu, Sep 24, 2009 at 12:16 AM, Richard Frith-Macdonald
<address@hidden> wrote:

On 24 Sep 2009, at 04:40, Matt Rice wrote:


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 :)

This sounds like an issue with the way gdb stores its breakpoints ... shouldn't it be storing more information so that it can disambiguate? I guess probably understanding this requires a fairly detailed knowledge of the symbol representation used in the libraries and in gdb ... which I lack. However, it's clear that at time point gdb is able to examine the binaries to get enough information to offer me a selection of places to break when I type 'break init' ... so there is sufficient information somewhere.

Now, for instance, if I type 'break init' I am presented with a numbered list of all the implementations of -init, and can type in a the number of an item to set a breakpoint in (for instance -[NSString init]. I would have expected gdb to record the fact that a breakpoint had been set in the NSString implementation of init rather than any other implementation, and be able to use that to determine which implementation in a newly loaded shared library should be used. I can also type in '1' to set a breakpoint in *all* implementations of init ... in which case, why would we care if there are multiple addresses in a newly loaded library .. we want all of them anyway.

Anyway ... perhaps it's not that straightforward, and perhaps even if it *is* that straightforward conceptually it's still a lot of work to implement changes., so I'm not trying to second-guess the basic objection.


+[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?

The '?method' syntax would not have occurred to me.
I just thought that keeping on using square brackets would be familiar in objc. Another possibility might be 'wildcarding' the class name rathe than simply omitting it
[* method] or [? method]
but I think I prefer the simple omission of the class name.

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.

I don't really consider rbreak a viable alternative as it's too clumsy for routine use ...

1. you have to remember that it's using a regular expression, and put in correct limitations to avoid getting far too many matches (try 'rbreak class' for instance). 2. it doesn't present you with a list of possible matches and ask you to select the one you want ... instead it tries to set breakpoints in all the matching methods and gives you a load of yes/no questions about methods in classes not yet loaded.

So yes, it's *possible* to use it, but it's not a good substitute for 'break methodname'

reply via email to

[Prev in Thread] Current Thread [Next in Thread]