site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jQPFYXzxOKUBZAtPaHVr6nQqf+meUSB5qMAZaBM8fN4=; b=cHufQkSQ9ypm5CXiKxnnKbUneCAtNe5mw5THxqMXVilM+B0I3YmtjDM017wRio9c37 i82u+sTSJCHtB3mTsBKbF596Om3ebJWJ0fTFAAq880IsPIIschCG1Ucl3csvP6lBrxIc PZY7t/lLPN0aVKKUqi0T2e85k9qLuYU0rzNghKUa2a8yjLDcGdEpJRxg5XZC9xAnKjcl 9FICCdD1EiMQzoa8uUvGALrjPxLIq8ueFjl6fbXkTfJV2v68juznWMRlFp/OoCDq0hAA ZOEFffrgT537MnO1+zhcmts1Brvq9jJFBXeGjIHUfhTgYrrwnffnIw0DSaiwsLKddtVU 6QcQ== Yeah, my build breaks if I don't ensure that the architecture project's include dir is earlier in the import precedence than EXTERNAL_HEADERS. The stuff in EXTERNAL_HEADERS still seems to make its way into the generated System/Kernel.framework though, so even on the latest Xcode, I see that this path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk//System/Library/Frameworks/Kernel.framework/Versions/A/Headers/architecture/i386/asm_help.h contains an outdated macro for PICIFY (and presumably other parts of the file are similarly outdated). Not sure whether the best fix is to just update the contents of the EXTERNAL_HEADERS folder or rearrange how the build works, but I figured I'd point it out to the broader community (and maintainers) since I wasted a good few hours figuring out how anything was supposed to work at all with a header that seemingly hadn't been updated since the 32-bit days. Thanks, Dan On Wed, Oct 11, 2017 at 3:25 PM, Greg Parker <gparker@apple.com> wrote:

On Oct 10, 2017, at 9:08 PM, Daniel Peebles <pumpkingod@gmail.com> wrote:

Hi all,

I'm trying to understand the purpose of the EXTERNAL_HEADERS folder in the XNU releases. I'm currently struggling to compile XNU 3248.60.10's libsyscall and my build is getting thrown off by the asm_help.h inside EXTERNAL_HEADERS, which tries to inject i386 code into my x86_64 syscall wrappers.

As an example, see https://opensource.apple.com/source/xnu/xnu-3248.60.10/ EXTERNAL_HEADERS/architecture/i386/asm_help.h.auto.html, which defines a PICIFY macro near the bottom. The one in there unconditionally runs popl %edx, which isn't valid in 64-bit mode.

If instead we compare the same asm_help.h from https://opensource.apple. com/source/architecture/architecture-268/i386/asm_help.h.auto.html (which comes from the same macOS release, 10.11.6), the same PICIFY macro correctly branches based on architecture and runs a far more appropriate movq var@GOTPCREL(%rip),%r11 on 64-bit intel.

This doesn't seem to affect most builds of XNU (such as those Shantonu Sen so helpfully explains on his blog) because the standard macOS SDKs include the more moderbn asm_help.h in the standard headers.

That leaves me wondering why EXTERNAL_HEADERS is provided in the first place, since it feels very confusing to those of us compiling in non-standard environments. It never seems to change (even the new darwin-xnu project on GitHub with the 10.13 kernel sources still has the old 32-bit file: https://github.com/apple/darwin-xnu/blob/master/ EXTERNAL_HEADERS/architecture/i386/asm_help.h#L270-L275).

Can anyone shed light on these apparent discrepancies?

The old copy of asm_help.h in xnu's EXTERNAL_HEADERS is probably leftover historical cruft. I bet libsyscall is expecting the more recent asm_help.h file from Darwin's 'architecture' project. https://opensource.apple.com/source/architecture/architecture-268/

-- Greg Parker gparker@apple.com Runtime Wrangler

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com