Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
- Subject: Re: Suppressing LC_DATA_IN_CODE and LC_FUNCTION_STARTS load commands in kexts
- From: Shantonu Sen <email@hidden>
- Date: Fri, 21 Sep 2012 13:06:20 -0700
Are you sure you are building with -mmacosx-version-min=10.7? What is your full link line for your i386 kext?
Shantonu
On Sep 21, 2012, at 12:27 PM, Phil Jordan <email@hidden> wrote:
> Hi,
>
> I've been having weird issues with my kexts and booting recently and
> only just figured out what's going on from a system log line I get
> upon touching /SLE:
>
> com.apple.kextcache: kxld[com.ssdcache.driver.SSDCache]: The Mach-O
> file is malformed: Invalid segment type in MH_OBJECT kext: 38.
>
> This causes the kext not to be prelinked.
>
>
> I've traced this output to a line in init_from_final_linked_image() in
> /xnu/libkern/kxld/kxld_object.c:
> kxld_log(kKxldLogLinking, kKxldLogErr, kKxldLogMalformedMachO
> "Invalid segment type in MH_KEXT_BUNDLE kext: %u.", cmd_hdr->cmd)
>
> Decimal 38 is 0x26 hex, and according to loader.h this means
> LC_FUNCTION_STARTS. Lo and behold, according to "otool -arch i386 -lv"
> the i386 part of my kext does indeed have such a segment (the x86_64
> one does not).
>
> It turns out that the Mountain Lion kxld will actually accept
> LC_FUNCTION_STARTS segments (though lacking an i386 kernel, it's
> actually irrelevant) but 10.7.x and earlier don't like it. (the
> difference between versions is pretty obvious in the switch block
> surrounding the above code) It further turns out that this segment
> wasn't generated by XCode 4.4.1's linker, but XCode 4.5's adds it for
> some reason. I'll file a relevant bug as soon as Radar comes back up.
>
>
> So for now, I'm looking for a work-around other than going back to XCode 4.4.1:
>
> Googling around a bit, I managed to find the linker flag
> -no_function_starts, which gets rid of LC_FUNCTION_STARTS, but then I
> get the same kxld system log line as before, though this time with
> number 41 aka 0x29 aka LC_DATA_IN_CODE. This segment is whopping 0
> bytes long, so it's obviously important!
>
> I've been unable to find a linker flag that gets rid of it - how do I
> suppress that command being generated, or is there a way to strip it
> afterwards?
>
> Thanks,
> phil
>
> --
> http://philjordan.eu/ - Phil Jordan, software development contractor
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden