Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

Zenith432
Zenith432
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.

Funny. Whereas CLOVERX64.efi became smaller (664K → 647K), the drivers became much larger—e.g. OsxAptioFix2Drv.efi went 18K → 24K.

Link to comment
Share on other sites
dgsga
dgsga
Posted
Posted

clang is set up in Clover.dsc to use -Os on all modules.  GCC uses -O3 on a couple, and -O0 on others.  However, GCC is set up to use lto (link-time-optimization). clang isn't.  clang has -flto as well, but it needs modifying the command given to ld in order to set up.  I haven't tried that because the firmware crashes with an exception anyway.

@ Zenith432

If you type ld -v in El Cap 10.11.5 you get:

 

 @(#)PROGRAM:ld  PROJECT:ld64-264.3.101

configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)

LTO support using: LLVM version 7.3.0

 

So we know that the native toolset supports LTO. I tried compiling with the -flto flag but the build fails:

 

...[CC] Reclaim

[CC] NullMemoryTest

[CC] CapsuleService

ld: in /Users/-/src/edk2/Build/Clover/RELEASE_XCLANG/X64/MdePkg/Library/BaseMemoryLib/BaseMemoryLib/OUTPUT/BaseMemoryLib.lib(SetMem.obj), archive member 'SetMem.obj' with length 1792 is not mach-o or llvm bitcode for architecture x86_64

make: *** [/users/-/src/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll] Error 1...

 

Unfortunately I have no idea how to fix this!

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted (edited)

Ummm.... sorry, but I only set up the -xcode5 toolchain for compiling with lto :)  If that doesn't work for you, I'll look into adapting the other clang-based toolchains tomorrow.

 

Update: Committed rev 3432 with clang toolchains as follows

  • -clang (XCLANG) updated to use lto and removed -all_load
  • -xcode (XCODE32) removed -all_load, but no lto as this is legacy support for old clang 3.2 on SnowLeopard
  • -llvm (LLVM) made no change as it's some hybrid between clang and gcc linker

-xcode5 is preferred method for building with current xcode.  -clang if you install your own self-built clang from llvm.org.

 

@ Zenith432

If you type ld -v in El Cap 10.11.5 you get:

 

 @(#)PROGRAM:ld  PROJECT:ld64-264.3.101

configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)

LTO support using: LLVM version 7.3.0

 

So we know that the native toolset supports LTO. I tried compiling with the -flto flag but the build fails:

 

...[CC] Reclaim

[CC] NullMemoryTest

[CC] CapsuleService

ld: in /Users/-/src/edk2/Build/Clover/RELEASE_XCLANG/X64/MdePkg/Library/BaseMemoryLib/BaseMemoryLib/OUTPUT/BaseMemoryLib.lib(SetMem.obj), archive member 'SetMem.obj' with length 1792 is not mach-o or llvm bitcode for architecture x86_64

make: *** [/users/-/src/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll] Error 1...

 

Unfortunately I have no idea how to fix this!

Edited by Zenith432
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

:(  XCODE5, ElCapitan 10.11.5, Xcode 7.2.1

iMac:Clover slice$ clang -v
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.5.0
Thread model: posix
iMac:Clover slice$

/Volumes/MacHD/Users/slice/src/edk2/MdePkg/Include/Base.h:503:11: error: unknown type name '__builtin_ms_va_list'; did you mean '__builtin_va_list'?
  typedef __builtin_ms_va_list VA_LIST;
          ^~~~~~~~~~~~~~~~~~~~
          __builtin_va_list
note: '__builtin_va_list' declared here
1 error generated.
  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Micky1979: The 32-bit -xcode5 build doesn't work.  It's not because of lto.  I tried turning off lto, and it still doesn't work.  With lto it hangs.  Without lto, it spontaneously reboots.

 

Update: It's probably the ABI, because x64 says x86_64-pc-win32-macho, but x86 does not have any ABI-related settings.  I'll look into it.

 

Slice:  __builtin_ms_va_list is a recent addition to clang.  See here.  You're right, Apple only merged it into their version in Xcode 7.3.  There's no resolution to this.  I tried using the older __builtin_va_list instead.  The result was boot7 works, CloverGUI works partially and can boot OS X, but some things don't work.  For instance, if I try start the shell - it hangs.  So __builtin_va_list works in some instances with ms-abi, and fails in others (I think va_copy is the problem, or maybe the number of fixed parameters.)

The manual implementation of va_list found in Base.h is not going to work anyway - because it assumes variable parameters are on the stack without spilling them.  There's no point in using it at all.

So to compile with -xcode5 need xcode 7.3.

  • Like 3
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Micky1979: The 32-bit -xcode5 build doesn't work.  It's not because of lto.  I tried turning off lto, and it still doesn't work.  With lto it hangs.  Without lto, it spontaneously reboots.

 

Update: It's probably the ABI, because x64 says x86_64-pc-win32-macho, but x86 does not have any ABI-related settings.  I'll look into it.

 

Slice:  __builtin_ms_va_list is a recent addition to clang.  See here.  You're right, Apple only merged it into their version in Xcode 7.3.  There's no resolution to this.  I tried using the older __builtin_va_list instead.  The result was boot7 works, CloverGUI works partially and can boot OS X, but some things don't work.  For instance, if I try start the shell - it hangs.  So __builtin_va_list works in some instances with ms-abi, and fails in others (I think va_copy is the problem, or maybe the number of fixed parameters.)

The manual implementation of va_list found in Base.h is not going to work anyway - because it assumes variable parameters are on the stack without spilling them.  There's no point in using it at all.

So to compile with -xcode5 need xcode 7.3.

OK, thanks for the analysis. Somehow Xcode 7.2.1 don't want to be updated to 7.3.

Anyway I created llvm-clang v3.8 with good support of ms_va_arg. I am using it to compile Wine, and it works! Same ms_abi as expected.

So why there is a toolset named XCLANG. 

But I don't know what is the rule to use LTO with clang. I think it is different from gcc-4.9. For example I have an utility llvm-lto and I see no its usage in our toolset. I want some theory about this.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

The problem with -xcode5 -ia32 is not in the ABI or var-args.

It is only in boot3.  If I use boot3 from gcc, CloverGUI and bdmesg from xcode work fine.

So it's a new problem specific to boot3.  It displays the digit "3" on top of the screen b4 hanging, so looks like BiosVideo succesfully initializes.

Will need more work.

 

Slice:

It may be that using LTO with vanilla clang requires adding --plugin liblto....  something to the command line to ar.  What error are you getting exactly?

Giving -flto to clang for compilation should work...

Must invoke ld via clang driver as usual with lto.

Does it fail during ar or ld?

 

crusher:

I'm not getting involved with Aptio.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Do you have DataHubDxe installed?

 

 

Slice:

It may be that using LTO with vanilla clang requires adding --plugin liblto....  something to the command line to ar.  What error are you getting exactly?

Giving -flto to clang for compilation should work...

Must invoke ld via clang driver as usual with lto.

Does it fail during ar or ld?

 

 

Something like invalid arguments. This evening I may try again.

Tested boot6 compiled as

-clang --std-ebda

Reboot after "6"

This digit printed on screen by INT10 so it has no relation to BiosVideo. It works before Protected mode inited.

#//Slice - switch to graphics mode (1), or 80x25 mono text mode (2)
		movw	$0x0002, %ax 
		int		$0x10
		#put char 6
		movl	$0x000F, %ebx
		movl	$0x0E36, %eax
		movl	$0x0010, %ecx
		int		$0x10

@STLVNUB

INT15h is also here so Coreboot is impossible.

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

yep, ar included in binutils is different from the built-in one, can be a big difference there? ..not sure.. but witch one are we using?
 
EDIT
I mean when "CC = clang" is reductive or we need to specify other like "CC = clang AR = ar NM = nm RANLIB = ranlib" etc.. to use built-in solution only? if have sense..offcourse

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

The article is not for clang. LTO is always specific for each compiler.

yep, ar included in binutils is different from the built-in one, can be a big difference there? ..not sure.. but witch one are we using?

 

EDIT

I mean when "CC = clang" is reductive or we need to specify other like "CC = clang AR = ar NM = nm RANLIB = ranlib" etc.. to use built-in solution only? if have sense..offcourse

It is defined in tools-def.txt file

#
# use xcode-select to change Xcode version of command line tools
#
*_XCODE5_*_CC_PATH      = clang
*_XCODE5_*_SLINK_PATH   = libtool
*_XCODE5_*_DLINK_PATH   = ld
*_XCODE5_*_ASM_PATH     = as
*_XCODE5_*_PP_PATH      = clang
*_XCODE5_*_VFRPP_PATH   = clang
*_XCODE5_*_ASL_PATH     = iasl
*_XCODE5_*_ASLCC_PATH   = clang
*_XCODE5_*_ASLPP_PATH   = clang
*_XCODE5_*_ASLDLINK_PATH  = ld
  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Slice:

I downloaded clang-3.8 Mac binary from llvm and tried it with -clang.

 

I think I understand the problem.

 

LLVM have their own version of ar called llvm-ar which has a different syntax from Apple ar or GCC ar

LLVM have their own version of ld called llvm-link which has a different syntax from Apple libtool or GCC ld

 

the XCLANG toolchain is set up to use Apple libtool and ar from whatever Xcode you have installed.

the LLVM toolchain is set up to use GCC ld and ar

 

I built "./ebuild.sh -clang" - boot6 with clang-3.8 I downloaded, and Xcode 7.3 that I have installed.  Resulting boot6 works.

build was done without lto as your latest commit.

Since this worked, I tried enable the lto stuff.

this didn't work

Because while lto stuff now uses clang driver for doing the link, it still uses ar from Apple Xcode 7.3.  Using ar from Apple doesn't work with clang-3.8 lto.  It needs llvm-ar (along with llvm-link which is probably what is invoked by clang.)

In order to set up llvm-ar it is necessary to modify the command line in build_rule.txt, as it has a different syntax.

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

LLVM have their own version of ar called llvm-ar which has a different syntax from Apple ar or GCC ar

LLVM have their own version of ld called llvm-link which has a different syntax from Apple libtool or GCC ld

 

 

In order to set up llvm-ar it is necessary to modify the command line in build_rule.txt, as it has a different syntax.

To modify the command line only for this toolset we have to create new rule? Or new tools family, not xcode? good.gif

No. I always UEFI mode and AptioFix and PartitionDxe driver. 

Best wishes!

Slice:

I downloaded clang-3.8 Mac binary from llvm and tried it with -clang.

 

Show me your version

llvm-clang -v

Link to comment
Share on other sites
tluck
tluck
Posted
Posted

yup. reverting to 20574 worked to build 3435 today.

 

something changed with these 2 files...

 

ver=20574
svn revert -q -R /Extra/Clover_Install/CloverGrowerPro/edk2
svn up --accept tf -r $ver /Extra/Clover_Install/CloverGrowerPro/edk2
Updating 'edk2':
A    edk2/IntelFrameworkModulePkg/Include/Protocol/Ps2Policy.h
U    edk2/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec

Fetching external item into 'edk2/BaseTools/Bin/Win32':
Updated external to revision 149.

At revision 20574.
 

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

To modify the command line only for this toolset we have to create new rule? Or new tools family, not xcode?

Show me your version

clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Volumes/Dev/toolchain/clang+llvm-3.8.0-x86_64-apple-darwin/bin/.
Here's the ar command in build_rule.txt as it is today

<Command.XCODE>

@"$(SLINK)" $(SLINK_FLAGS) ${dst} -filelist $(OBJECT_FILES_LIST)

@"echo" [sLINK] $(MODULE_NAME)

and the documentation for llvm-ar is found here.

I don't see how llvm-ar command line can fit into that prototype of a command line.

 

There is another possibility that llvm have a plugin that makes it possible to use Apple's ar with their lto files.  They have such a thing for linux called gold plugin.  Coudn't figure if there's such a thing for Apple.

 

Another possibility is to make a shell script to translate ar-like parameters to llvm-ar syntax.

 

It fails as this is meant to build with minimal patches, the way it is meant to be.

Here's a patch to correct the error introduced by EDK2@20575

diff --git a/BiosKeyboard/KeyboardDxe.inf b/BiosKeyboard/KeyboardDxe.inf
--- a/BiosKeyboard/KeyboardDxe.inf
+++ b/BiosKeyboard/KeyboardDxe.inf
@@ -45,6 +45,7 @@
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   IntelFrameworkPkg/IntelFrameworkPkg.dec
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
 
@@ -70,7 +71,7 @@
   gEfiDevicePathProtocolGuid                    # PROTOCOL ALWAYS_CONSUMED
 
 [FeaturePcd]
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPs2KbdExtendedVerification|FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdPs2KbdExtendedVerification|FALSE
   
 [BuildOptions]
 [BuildOptions]
I cannot commit this until ppl permanently move past 20575.

 

I'm out of ideas on -xcode5 -ia32 boot3. It just spontaneously reboots.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Hold on...

If you look in Xcode toolchain

Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

ls and ar are at usr/bin

and there's LLVM's plugin under

usr/lib/libLTO.dylib

 

and that is the plugin these tools use to handle LTO

In vanilla clang tree there's also

lib/libLTO.dylib

 

So if you put vanilla libLTO in your DYLD_LIBRARY_PATH so it is found first

then ld and ar from Xcode should use that instead of Apple's LTO.

And then be able to handle -clang LTO.

 

Update: Ummmmmm

 

 

clang version 3.8.0 (tags/RELEASE_380/final)

Target: x86_64-apple-darwin15.4.0

Thread model: posix

InstalledDir: /Volumes/Dev/toolchain/clang+llvm-3.8.0-x86_64-apple-darwin/bin

"/usr/bin/ld" -demangle -lto_library /Volumes/Dev/toolchain/clang+llvm-3.8.0-x86_64-apple-darwin/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.11.0 -o /Volumes/Dev/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll -u __ModuleEntryPoint -e __ModuleEntryPoint -preload -segalign 0x20 -pie -dead_strip -seg1addr 0x240 -map /Volumes/Dev/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.map -filelist /Volumes/Dev/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/OUTPUT/static_library_files.lst

[CC] MemLibGeneric

ld: in /Volumes/Dev/edk2/Build/Clover/RELEASE_XCLANG/X64/MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint/OUTPUT/UefiDriverEntryPoint.lib(DriverEntryPoint.obj), archive member 'DriverEntryPoint.obj' with length 4752 is not mach-o or llvm bitcode for architecture x86_64

clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [/Volumes/Dev/edk2/Build/Clover/RELEASE_XCLANG/X64/MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer/DEBUG/WatchdogTimer.dll] Error 1

otool -h DriverEntryPoint.obj

DriverEntryPoint.obj: is an LLVM bit-code file

ls -l DriverEntryPoint.obj

-rw-r--r-- 1 zenith432 staff 4748 Apr 13 17:05 DriverEntryPoint.obj

ar -tv UefiDriverEntryPoint.lib 

rw-r--r--     501/20           88 Apr 13 17:05 2016 __.SYMDEF SORTED

rw-r--r--     501/20         4752 Apr 13 17:05 2016 DriverEntryPoint.obj

go figure...

 

 

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Ok, I downloaded the source code to cctools which contains both libtool and ar.  This is the code in libstuff/lto.c used to look for the plugin

bufsize = MAXPATHLEN;
            p = buf;
            i = _NSGetExecutablePath(p, &bufsize);
            if(i == -1){
                p = allocate(bufsize);
                _NSGetExecutablePath(p, &bufsize);
            }
            prefix = realpath(p, resolved_name);
            p = rindex(prefix, '/');
            if(p != NULL)
                p[1] = '\0';
            lto_path = makestr(prefix, "../lib/libLTO.dylib", NULL);
 
            lto_handle = dlopen(lto_path, RTLD_NOW);
            if(lto_handle == NULL){
                free(lto_path);
                lto_path = NULL;
                lto_handle = dlopen("/Applications/Xcode.app/Contents/"
                                    "Developer/Toolchains/XcodeDefault."
                                    "xctoolchain/usr/lib/libLTO.dylib",
                                    RTLD_NOW);
            }
            if(lto_handle == NULL)
                return(0);
So it looks for the plugin...

in directory ../lib/libLTO.dylib relative itself

If not there in /Application/Xcode.app/....... in that string.

 

It does not help to put the dylib in DYLD_LIBRARY_PATH. Apple's libtool and ar look just in those 2 places. However, Apple's ld has command line option -lto_library <path> to point to the plugin.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted 
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Volumes/Dev/toolchain/clang+llvm-3.8.0-x86_64-apple-darwin/bin/.
Here's the ar command in build_rule.txt as it is today

and the documentation for llvm-ar is found here.

I don't see how llvm-ar command line can fit into that prototype of a command line.

 

There is another possibility that llvm have a plugin that makes it possible to use Apple's ar with their lto files.  They have such a thing for linux called gold plugin.  Coudn't figure if there's such a thing for Apple.

 

Another possibility is to make a shell script to translate ar-like parameters to llvm-ar syntax.

 

Here's a patch to correct the error introduced by EDK2@20575

diff --git a/BiosKeyboard/KeyboardDxe.inf b/BiosKeyboard/KeyboardDxe.inf
--- a/BiosKeyboard/KeyboardDxe.inf
+++ b/BiosKeyboard/KeyboardDxe.inf
@@ -45,6 +45,7 @@
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   IntelFrameworkPkg/IntelFrameworkPkg.dec
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
 
@@ -70,7 +71,7 @@
   gEfiDevicePathProtocolGuid                    # PROTOCOL ALWAYS_CONSUMED
 
 [FeaturePcd]
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPs2KbdExtendedVerification|FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdPs2KbdExtendedVerification|FALSE
   
 [BuildOptions]
 [BuildOptions]
I cannot commit this until ppl permanently move past 20575.

 

I'm out of ideas on -xcode5 -ia32 boot3. It just spontaneously reboots.

 

Don't worry!

We can force users to update edk2.

I committed this patch to 3436

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...