Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3205 posts in this topic

Recommended Posts

RehabMan
RehabMan
Posted
Posted

Xcode 7.3 is bad news for me...

 

It does not allow SDKs prior to 10.11 to be used. For several of my kext project, I build with older SDKs in order to provide compatibility with older systems (down to 10.6.8). Still debating as to whether I'm going to update all of them to 10.11 SDK (hence making the kexts incompatible with prior versions), or stick with the older Xcode 7.2.1 for now.

 

I guess Clover is built with current SDK.

tluck
tluck
Posted
Posted

@rehabman - there is a way to get 7.3code to use older SDKs - so as before -

in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

$ ls -l
total 16
lrwxr-xr-x  1 root  wheel   40 Mar 21 21:20 MacOSX10.10.sdk -> /Applications/Xcode_SDKs/MacOSX10.10.sdk
drwxr-xr-x  5 root  wheel  170 Oct 20  2020 MacOSX10.11.sdk
lrwxr-xr-x  1 root  wheel   39 Mar 21 21:20 MacOSX10.9.sdk -> /Applications/Xcode_SDKs/MacOSX10.9.sdk

 

but now edit the new key MinimumSDKVersion in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist

 

$ diff Info.orig.plist Info.plist
87c87
<  <string>10.11</string>
---
>  <string>10.9</string>

  • Like 2
Slice
Slice
Posted
Posted

Clover itself built without SDK.

But CloverUpdater, PrefPane etc. are not built in ElCapitan et all.

I used 10.7 or 10.9 with SDK10.7

 

OK, I got XCode 7.3 from AppStore.

Apple LLVM version 7.3.0 (clang-703.0.29)
orenmac
orenmac
Posted
Posted

Clover itself built without SDK.

But CloverUpdater, PrefPane etc. are not built in ElCapitan et all.

 

From Capitan, Xcode 7.3, gcc49:

Discard ../CloverUpdater/src/sv.lproj/CloverUpdater.strings (0 of 12 strings; only 0% translated; need 74%).
Discard ../CloverPrefpane/src/sv.lproj/CloverPrefpane.strings (0 of 39 strings; only 0% translated; need 74%).

Building CloverUpdater application...
[XCODE]
Building CloverPrefpane preference...
[XCODE]
================= Making all in fdisk440 =================

This is a not build?  :blush:  

I'm not coder, just for info

Slice
Slice
Posted
Posted

From Capitan, Xcode 7.3, gcc49:

Discard ../CloverUpdater/src/sv.lproj/CloverUpdater.strings (0 of 12 strings; only 0% translated; need 74%).
Discard ../CloverPrefpane/src/sv.lproj/CloverPrefpane.strings (0 of 39 strings; only 0% translated; need 74%).

Building CloverUpdater application...
[XCODE]
Building CloverPrefpane preference...
[XCODE]
================= Making all in fdisk440 =================
This is a not build?  :blush:  

I'm not coder, just for info

 

Unbelievable!

 --------------------------

 Building process complete!

 --------------------------

 

 Build info.

 ===========

  Package name: Clover_v2.3k_r3435.pkg

  MD5:          973f01edf94b5ae4ec4e9597298350c0

  Version:      v2.3k

  Stage:        v2.3k

  Date/Time:    2016-04-13 20:33:19

  Built by:     slice

  Copyright     2012-2016

 

  adding: Clover_v2.3k_r3435.pkg (deflated 0%)

  adding: Clover_v2.3k_r3435.pkg.md5 (stored 0%)

total 159848

just updated Xcode 7.3!

Xcode 7.3 is bad news for me...

 

It does not allow SDKs prior to 10.11 to be used. For several of my kext project, I build with older SDKs in order to provide compatibility with older systems (down to 10.6.8). Still debating as to whether I'm going to update all of them to 10.11 SDK (hence making the kexts incompatible with prior versions), or stick with the older Xcode 7.2.1 for now.

 

I guess Clover is built with current SDK.

Can you compile kexts for ia32?

I can do this only in 10.7.5.

 

 

The clang compiler does not support 'fapple-kext' for C++ on Darwin/i386
  • Like 1
RehabMan
RehabMan
Posted
Posted

Can you compile kexts for ia32?

I can do this only in 10.7.5.

 

The clang compiler does not support 'fapple-kext' for C++ on Darwin/i386

 

No. I get the same error. I build all kexts 64-bit only. I have no need for 32-bit.

 

Using an older Xcode is the only option I found for 32-bit (or fat binaries).

 

 

--

@rehabman - there is a way to get 7.3code to use older SDKs - so as before -

in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

$ ls -l

total 16

lrwxr-xr-x  1 root  wheel   40 Mar 21 21:20 MacOSX10.10.sdk -> /Applications/Xcode_SDKs/MacOSX10.10.sdk

drwxr-xr-x  5 root  wheel  170 Oct 20  2020 MacOSX10.11.sdk

lrwxr-xr-x  1 root  wheel   39 Mar 21 21:20 MacOSX10.9.sdk -> /Applications/Xcode_SDKs/MacOSX10.9.sdk

 

but now edit the new key MinimumSDKVersion in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist

 

$ diff Info.orig.plist Info.plist

87c87

<  <string>10.11</string>

---

>  <string>10.9</string>

Seems to work...

 

I updated my legacysdks.sh script:

#!/bin/bash

osxplatform=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
sdkrepo=$osxplatform/Developer/SDKs/
infoplist=$osxplatform/Info.plist

for sdk in /Applications/LegacySDKs/*.sdk; do
   sudo ln -s $sdk $sdkrepo`basename $sdk`
done
ls -l $sdkrepo

sudo /usr/libexec/PlistBuddy -c "Set :MinimumSDKVersion 10.6" $infoplist
zxv
zxv
Posted
Posted

Try again with rev 3431.  I've set up LTO for clang -xcode5 toolchain, and removed -all_load linker option that was causing unnecessary bloat.

Yeah, I get build fails i.e. "clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)" w/ the '-all-load' opt removed; I see slice added '-all-load' back into a later revision, and it works again.

 

Thanks for your help in bettering the Clover build process, btw.

Zenith432
Zenith432
Posted
Posted

It's not the removal of -all_load, it was the -flto causing the error.  With -clang you don't get lto.  With -xcode5 you get lto.

 

The -all_load probably doesn't do anything, because -dead_strip should undo it.

 

Yeah, I get build fails i.e. "clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)" w/ the '-all-load' opt removed; I see slice added '-all-load' back into a later revision, and it works again.

Slice
Slice
Posted
Posted

Hi Zenith432,

Good!

I found 6 such functions in the project, we should find a working one.

I said 6, you corrected 4.

CpuDxe affected as well and it used in CloverEFI.  :wink_anim:


^^ Great!

@DEVS, please dont drop SL support :D

Old computer, old system -> old Clover.

  • Like 2
Slice
Slice
Posted
Posted

New problem: clover-genconfig.

 

It includes Platform.h -> Base.h

and now as it is clang it uses ms_va_args.

This is wrong. The utility will work in MacOSX and must use builtin_va_args.

Somewhere should by TARGET=MACOSX

Zenith432
Zenith432
Posted
Posted

I found 6 copies of LegacyBiosThunk.c under edk2/ (outside of Trash), so that's what I thought you were talking about. The 2 copies not in Clover are not used.

I said 6, you corrected 4.

CpuDxe affected as well and it used in CloverEFI.  :wink_anim:

-xcode5 -ia32 still reboots with additional fix, so it's a different problem.

 

This is my fault then. Didn't know Base.h gets #included in non-EFI code.

New problem: clover-genconfig.

 

It includes Platform.h -> Base.h

and now as it is clang it uses ms_va_args.

This is wrong. The utility will work in MacOSX and must use builtin_va_args.

Somewhere should by TARGET=MACOSX

chris1111
chris1111
Posted
Posted

New Clover has support for Haswell and Skylake which are not supported by SL. What else did you expected?

Same for graphics cards, for new MacModels etc.

Slice You are Inspiring me and last week I buy new PC

Lenovo ThinkCentre and I install easy Snow Leopard and El Capitan 10.11.5 Beta

I used Clover r3428 working good ESP  :thumbsup_anim:

 

see  :: http://img15.hostingpics.net/pics/990394snow.png

chris1111
chris1111
Posted
Posted

Mostly new Clover will work on SL. I compile all utility with MinMacosVersion=10.6.

But I am not testing if all is OK with SL.

Boot Time is super fast !Alf. Spining wheel

Mount EFI work by the panel but slow for mounting

and same thing for updater slow to open

But in générale everything is perfect shut down Right a way

Thanks anyway

Zenith432
Zenith432
Posted
Posted

I found the reason -xcode5 -ia32 is crashing.  It's a bug in nasm when generating pc-relative relocations for macho32.

 

Here's an example

 

 

#include <stdio.h>
 
extern int foo(void);
 
int main(int argc, char** argv)
{
printf("%d\n", foo());
}
generates (clang -arch i386...)

(__TEXT,__text) section
_main:
00000000	55              	pushl	%ebp
00000001	89e5            	movl	%esp, %ebp
00000003	83ec18          	subl	$0x18, %esp
00000006	e800000000      	calll	0xb
0000000b	58              	popl	%eax
0000000c	8b4d0c          	movl	0xc(%ebp), %ecx
0000000f	8b5508          	movl	0x8(%ebp), %edx
00000012	8955fc          	movl	%edx, -0x4(%ebp)
00000015	894df8          	movl	%ecx, -0x8(%ebp)
00000018	8945f4          	movl	%eax, -0xc(%ebp)
0000001b	e8e0ffffff      	calll	_foo    <<----- Notice the value inserted for the relocation (-0x20)
00000020	8b4df4          	movl	-0xc(%ebp), %ecx
00000023	8d9136000000    	leal	65-11(%ecx), %edx
00000029	891424          	movl	%edx, _main(%esp)
0000002c	89442404        	movl	%eax, 0x4(%esp)
00000030	e8cbffffff      	calll	_printf <<----- Notice the value inserted for the relocation (-0x35)
00000035	31c9            	xorl	%ecx, %ecx
00000037	8945f0          	movl	%eax, -0x10(%ebp)
0000003a	89c8            	movl	%ecx, %eax
0000003c	83c418          	addl	$0x18, %esp
0000003f	5d              	popl	%ebp
00000040	c3              	retl
Here's what nasm does

extern _foo

mov eax, 3
mov ebx, 4
add ebx, eax
call _foo
mov edx, 5
(assembled with nasm -macho32....)

(__TEXT,__text) section
00000000	b803000000      	movl	$0x3, %eax
00000005	bb04000000      	movl	$0x4, %ebx
0000000a	01c3            	addl	%eax, %ebx
0000000c	e800000000      	calll	_foo+17  <<----- notice wrong value pluggued in 0 instead of -0x11
00000011	ba05000000      	movl	$0x5, %edx

 

Zenith432
Zenith432
Posted
Posted (edited)

The problem is with 'nasm -f macho32....'.  GCC toolchain uses same nasm, but 'nasm -f elf32...' which does not suffer from this bug.

Hm, nasm used in GCC49 toolchain that works. It not used with clang. .S files compiled by clang itself.

 

Update: I committed a workaround for this in rev 3441.  Problem solved.  -xcode5 -ia32 works.

 

Clover can be built with -xcode5 now which uses lto in both 32 and 64-bit builds.

-xcode5 -ia32 can be built using Xcode 7.3 and also earlier versions of Xcode.

-xcode5 X64 variants require Xcode 7.3 due to dependence on --builtin_ms_va_list.

Edited by Zenith432
  • Like 1
Zenith432
Zenith432
Posted
Posted

This issue with dereferencing null pointers is one of the optimizations.  For instance

 

#include <stdlib.h>

int vec(int index)
{
	return ((int*) NULL)[index];
}

compiled with 'clang -c -O0...' gives

(__TEXT,__text) section
_vec:
0000000000000000	55              	pushq	%rbp
0000000000000001	4889e5          	movq	%rsp, %rbp
0000000000000004	31c0            	xorl	%eax, %eax
0000000000000006	89c1            	movl	%eax, %ecx
0000000000000008	897dfc          	movl	%edi, -0x4(%rbp)
000000000000000b	486355fc        	movslq	-0x4(%rbp), %rdx
000000000000000f	8b0491          	movl	_vec(%rcx,%rdx,4), %eax
0000000000000012	5d              	popq	%rbp
0000000000000013	c3              	retq

compiling with 'clang -c -Os...' gives

(__TEXT,__text) section
_vec:
0000000000000000	55              	pushq	%rbp
0000000000000001	4889e5          	movq	%rsp, %rbp
0000000000000004	0f0b            	ud2

 



In GCC, there's an option '-fno-delete-null-pointer-checks' to turn off this optimization. There is an open bug for supporting it in clang.

  • Like 1
DoiX
DoiX
Posted
Posted

Clover is using the wrong device id for HD 530


{ 0x191A, "Intel HD Graphics 530"  }, // Intel(R) HD Graphics 530

It should be 0x191B, as it was in revision 3368. After that revision it got changed to the current id.

 Share
Go to topic listing
×
×
  • Create New...