Re: XNU's EXTERNAL_HEADERS folder and seemingly outdated headers in it
Re: XNU's EXTERNAL_HEADERS folder and seemingly outdated headers in it
- Subject: Re: XNU's EXTERNAL_HEADERS folder and seemingly outdated headers in it
- From: Daniel Peebles <email@hidden>
- Date: Thu, 12 Oct 2017 12:03:52 -0400
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 <email@hidden> wrote:
>
> On Oct 10, 2017, at 9:08 PM, Daniel Peebles <email@hidden> 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
> íx, 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 email@hidden Runtime Wrangler
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden