Is the sender of an obj-c method implied in the destination's method?

  • So my method just got called, [anObject called]. I'm wondering, does
    an implied reference exist to the caller from inside called, like self
    and _cmd? I'm looking at NSInvocation, but it doesn't look like
    there's an  +[NSInvocation currentInvocation] type method.

    Is there a way to get this information without explicitly passing the
    caller in as a parameter? Would be cool.

    ~Phi

    Journler Developer
    <phil...>
  • On Dec 10, 2007, at 8:51 PM, Philip Dow wrote:

    > So my method just got called, [anObject called]. I'm wondering, does
    > an implied reference exist to the caller from inside called, like
    > self and _cmd? I'm looking at NSInvocation, but it doesn't look like
    > there's an  +[NSInvocation currentInvocation] type method.
    >
    > Is there a way to get this information without explicitly passing
    > the caller in as a parameter? Would be cool.

    No.

    j o a r
  • On Dec 10, 2007, at 8:51 PM, Philip Dow wrote:
    > So my method just got called, [anObject called]. I'm wondering, does
    > an implied reference exist to the caller from inside called, like
    > self and _cmd? I'm looking at NSInvocation, but it doesn't look like
    > there's an  +[NSInvocation currentInvocation] type method.
    >
    > Is there a way to get this information without explicitly passing
    > the caller in as a parameter? Would be cool.

    It isn't explicitly available, nor can you consistently unwind the
    stack to figure it out.  Nor is there even a guarantee that the
    "sender" is really some Objective-C object;  it could just as easily
    be a function or FFI produced closure, in the case of the various
    language bridges.

    b.bum
  • Just out of curiosity, why is stack unwinding considered
    inconsistent? It has to work well enough for zero-cost exception
    handling to function, in the "new" frameworks at least...

    On Dec 10, 2007, at 9:06 PM, Bill Bumgarner wrote:

    > On Dec 10, 2007, at 8:51 PM, Philip Dow wrote:
    >> So my method just got called, [anObject called]. I'm wondering,
    >> does an implied reference exist to the caller from inside called,
    >> like self and _cmd? I'm looking at NSInvocation, but it doesn't
    >> look like there's an  +[NSInvocation currentInvocation] type method.
    >>
    >> Is there a way to get this information without explicitly passing
    >> the caller in as a parameter? Would be cool.
    >
    > It isn't explicitly available, nor can you consistently unwind the
    > stack to figure it out.  Nor is there even a guarantee that the
    > "sender" is really some Objective-C object;  it could just as
    > easily be a function or FFI produced closure, in the case of the
    > various language bridges.
    >
    > b.bum
  • On 11 Dec 2007, at 05:24, John Stiles wrote:

    > Just out of curiosity, why is stack unwinding considered
    > inconsistent? It has to work well enough for zero-cost exception
    > handling to function, in the "new" frameworks at least...

    First, in the case of zero-cost exception handling, the stack layout
    and the exception handling are entirely under the control of the
    compiler.  Second, even in that case, the runtime only needs to be
    able to unwind methods that contain exception handlers or that
    otherwise need cleanup for some reason.

    On both PowerPC and Intel, it's quite possible for a function to run
    without a "proper" stack frame, or for it to jump to the thing that
    it's calling in such a way that its stack frame is replaced by that of
    the function it called.  Neither of those things matter for exception
    handling because the compiler either (a) won't generate code that way
    for functions with exception handlers, or (b) knows how to inform the
    runtime that it's done something like that.  They do matter, though,
    if you try to unwind the stack "by hand".

    But the original question was about finding the sender of an ObjC
    message; I think the OP assumed that this would always be an object,
    which is plainly not the case, but even if it were, you couldn't
    always recover information about the sending object by walking the
    stack frames because you simply don't know where that information is,
    *particularly* on PowerPC or 64-bit Intel where some arguments will
    have been passed in registers which may subsequently have been
    overwritten.  (On PowerPC, there is at least a standard place in the
    stack frame for a function to save the contents of those registers;
    however, not all code does that since it isn't compulsory.  I'm not
    familiar with the 64-bit x86 ABI, so I can't comment there.)

    You can see the effects of these types of problems from GDB's "bt"
    output.  It's usually quite good at finding the arguments for
    functions/methods, and *often* lists a complete backtrace, but
    occasionally you'll find that it hasn't got it right, and *it* has the
    advantage of having the debug information accessible...

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today