• 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: Can an NSString literal's bytes be moved to a different section of the executable?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can an NSString literal's bytes be moved to a different section of the executable?


  • Subject: Re: Can an NSString literal's bytes be moved to a different section of the executable?
  • From: Jean-Daniel Dupas <email@hidden>
  • Date: Thu, 25 Feb 2016 10:34:24 +0100


Le 25 févr. 2016 à 02:26, Jens Alfke <email@hidden> a écrit :

Is there a way to control which section of the executable a specific NSString literal goes into? I’ve tried using the ‘section’ attribute, but it has no effect:
__attribute__((section(“__TEXT,__foo”))) static NSString* const kFoo = @“Foobar”;
The above doesn’t change where the string appears; there is no __TEXT,__foo section in the binary at all, and the string is still in the default __TEXT,__cstring section.

I’m asking because the project I work on includes a lot of logging calls, which are left in the release build so that logging can be turned on for troubleshooting in the field, but for reasons of cache locality I’d like the resulting strings (and ideally the code) not to be mixed in with the rest of the executable.

(Moving the code itself out of the way seems to be a non-starter. I’ve tried using some macro hackery to put the actual _log(…) call in a block, but adding a ‘section’ attribute to the block produces a compiler error saying that only functions and globals can have a section assigned.)

—Jens

If your code is performance sensitive enough that you have to consider cache locality of static strings, you may consider replacing your logging code by dtrace USDT (User-Level Statically Defined Tracing). 

The main benefit is that when disabled, they cost almost nothing (not even a branch as traditional log does).

To do that, you just create a primes.d file that contains the list of probe you want to define:

provider primes {
/* Start of the prime calculation */

   probe primecalc__start(long prime);

/* End of the prime calculation */

   probe primecalc__done(long prime, int isprime);

/* Exposes the size of the table of existing primes */

   probe primecalc__tablesize(long tablesize);
};

You add that file to your Xcode project, and it will automatically generate the corresponding header.

You can the include the header in your source:

--------
#include "primes.h"

long prime(long value) {
PRIMES_PRIMECALC_START(value);
    ….
    PRIMES_PRIMECALC_DONE(result);
    if (PRIMES_PRIMECALC_TABLESIZE_ENABLED()) {
     // Do some computation useless when probe disabled.
        PRIMES_PRIMECALC_TABLESIZE(size);
    }
}
--------

Note that even if some code is conditionally protected by a if branch, the linker replace it at link time by custom dtrace code, so you don’t have to pay for it (dtrace is designed to cost nothing when disabled).


 _______________________________________________
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

References: 
 >Can an NSString literal's bytes be moved to a different section of the executable? (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Can an NSString literal's bytes be moved to a different section of the executable?
  • Next by Date: Missing vars in Swift-ified interface
  • Previous by thread: Re: Can an NSString literal's bytes be moved to a different section of the executable?
  • Next by thread: Missing vars in Swift-ified interface
  • Index(es):
    • Date
    • Thread