• 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: What?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What?


  • Subject: Re: What?
  • From: Stephen Hoffman <email@hidden>
  • Date: Fri, 30 May 2008 14:53:49 -0400
  • Organization: HoffmanLabs LLC


My head is spinning.
In other (more general?) terms...

Executable code typically contains the addresses of data (eg: fetch, store) or the address of instructions elsewhere within the particular hunk of code (eg: branch).

If you include absolute addresses in the code, then the code has to be mapped into the specified address range, or the address references won't work. The code is position-dependent.

The image loader then has to fill in the checker-board of the address space as hunks and pieces are mapped, finding and filling where it can or must fit.

Or the loader punts, when there are address space conflicts. When two hunks of code would otherwise end up overlapping.

The alternatives to position-dependence include what is variously known as a "fix-up" in the image loader or image activator or whatever the particular platform calls it; where launching the image includes processing which finds and fixes these addresses when the code is mapped and for where-ever the code is mapped into the address space. Alternatively (and when the instruction set permits it) where the offsets are all base- or segment-relative; where the target data or code addresses are stored as offsets and the addresses are computed by the processor at run-time. This code is position-independent.

With position-independent code, the image loader can then load constituent hunks where-ever it has room in address space. Dynamic loading (qv: the dlopen() C call) has the same flexibility with these images, for code that's loaded at run-time.

The difference between position-dependent and position-independent is minor and not something I've ever seen in the wild outside of a very few degenerate cases. Where permissible, I tend to prefer to generate the latter, though it does incur very slight penalties for the fix-ups or the offset calculations. The overhead is usually lost down in the noise, however.

This processing is analogous to how virtual memory is implemented. Well worth your time understanding how that works (in general, or for a specific box), if you haven't looked into an implementation.

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


  • Follow-Ups:
    • Re: What?
      • From: Julian Vrieslander <email@hidden>
  • Prev by Date: Re: What?
  • Next by Date: Re: What?
  • Previous by thread: Re: What?
  • Next by thread: Re: What?
  • Index(es):
    • Date
    • Thread