• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: selector data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: selector data


  • Subject: Re: selector data
  • From: Damien Bobillot <email@hidden>
  • Date: Sun, 12 Feb 2006 22:51:31 +0100

Braden Thomas wrote :

Hello cocoa-dev,
I have a question about the mach-o binary format and how it pertains to cocoa. I've noticed that in some simple cocoa applications, the selectors are loaded in memory right along with the code, which seems to always starts at 0x1000 when the binary is loaded.
However, in other cocoa applications, when the binary is loaded, the selectors go into another part of memory that's much higher, in fact an address that's greater than the size of the binary itself. Now of course, this must be defined at compile-time (how else could the compiler generate code), but I can't seem to figure out how I can find the real memory address without actually loading the binary. It must be stored somewhere in some header? :-\

The selectors names are stored where the compiler decides, wherever it wants. The only important thing is that it must issue the good assembly code to refer to the good position. There are possibilities :
- using a relative offset from the PC, position of the current instruction (method used for apps (?))
- using a offset from the TOC, register containing the address of the beginning of the data section (= default values for global variables and constant data like sector names) of the executable (method used for libs (?))


Another thing to know is that the stored code in the program binary is not loaded as is in memory. The binary is divided in sections, and, for each section, the compiler adds the absolute memory address at which the section must be loaded. The loader loads each section independently, and at different address : it explains why the selectors may be at a memory address greater than the size of the executable file.

My answer is not very precise (because executable loading with support to dynamic linking to libraries is a bit complex). However, if you need more information, try to look at documentations (from Apple or other sources) about dynamic linking, relocations, the mach- o executable file format, the Objective-C runtime, the "otool" command…

Good luck,

--
Damien Bobillot

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >selector data (From: Braden Thomas <email@hidden>)

  • Prev by Date: NSUserDefaults for portable applications
  • Next by Date: Re: Converting HIPoints to CGPoints/NSPoints in global space?
  • Previous by thread: Re: selector data
  • Next by thread: Re: Modifying HTML Content of a WebFrame
  • Index(es):
    • Date
    • Thread