Unresolved external symbol __aullshr when optimization is turned off

Question

I am compiling a piece of UEFI C code with Visual Studio 2015 C/C++ compiler. The compiler is targeting IA32, not X64. When turning on the optimization with "/O1", the build is OK. When turning off the optimization with "/Od", the build gives below error: ``` error LNK2001: unresolved external symbol __aullshr ``` According to here, there's an explanation why this kind of functions can be called implicitly by the compiler: It turns out that this function is one of several compiler support functions that are invoked explicitly by the Microsoft C/C++ compiler. In this case, this function is called whenever the 32-bit compiler needs to multiply two 64-bit integers together. The EDK does not link with Microsoft's libraries and does not provide this function. Are there other functions like this one? Sure, several more for 64-bit division, remainder and shifting. But according to here: ...Compilers that implement intrinsic functions generally enable them only when a program requests optimiz…

Accepted Answer

Your build setup for creating UEFI applications omits the static library of helper functions that MSVC's code-gen expects to be available. MSVC's code-gen sometimes inserts calls to helper functions, the same way that gcc does for 64x64 multiply or divide on 32-bit platforms, or various other things. (e.g. popcount on targets without hardware popcnt.)

In this case hand-holding MSVC into less-stupid code-gen (a good thing in itself) happens to remove all the uses of helper functions for your codebase. That's good but doesn't fix your build setup. It can break again if you add code in the future that needs a helper. `uint64_t shr(uint64_t a, unsigned c) { return a >> c; }` does compile to include a call to the helper function even at `-O2`.

A shift by a constant without optimization uses `_aullshr`, instead of inlining as `shrd` / `shr`. This exact problem (broken `-Od` builds) would recur with `uint64_t x` ; `x >> 4` or something in your source.

(I don't know where MSVC keeps its library of helper functions. We think it's a static library that you could link without introducing a DLL dependency (impossible for UEFI), but we don't know if its maybe bundled with some CRT startup code that you need to avoid linking with for UEFI.)

The un-optimized vs. optimized issue is clear with this example. MSVC with optimization doesn't need the helper function, but its braindead `-Od` code does.

For bitfield access, MSVC apparently uses a right shift of the base type of the bitfield member. In your case, you made it a 64-bit type, and 32-bit x86 doesn't have a 64-bit integer shift (except using MMX or SSE2). With `-Od` even for constant counts it puts the data in EDX:EAX, the shift count in `cl` (just like for x86 shift instructions), and calls `__aullshr`.

- `__a` = ??

- `ull` = unsigned long long.

- `shr` = shift right (like the x86 asm instruction of the same name).

- it takes the shift count in `cl`, exactly like x86 shift instructions.

From the Godbolt compiler explorer, x86 MSVC 19.16 `-Od`, with `UINT64` as the bitfield member type.

```
;; from int Method1(unsigned __int64) PROC 
    ...
   ; extract IssueStruct.Bits.field8
    mov     eax, DWORD PTR _IssueStruct$[ebp]
    mov     edx, DWORD PTR _IssueStruct$[ebp+4]
    mov     cl, 57                                    ; 00000039H
    call    __aullshr        ; emulation of   shr  edx:eax,  cl
    and     eax, 1
    and     edx, 0
    ;; then store that to memory and cmp/jcc both halves.  Ultra braindead
```

Obviously for constant shift and access to only 1 bit, that's easy to optimize, so MSVC doesn't actually call the helper function at `-O2`. It's still pretty inefficient, though! It fails to fully optimize away the 64-bitness of the base type, even though none of the bitfields are wider than 32.

```
; x86 MSVC 19.16 -O2   with unsigned long long as the bitfield type
int Method1(unsigned __int64) PROC                              ; Method1, COMDAT
    mov     edx, DWORD PTR _Data$[esp]       ; load the high half of the inputs arg
    xor     eax, eax                         ; zero the low half?!?
    mov     ecx, edx                         ; copy the high half
    and     ecx, 33554432       ; 02000000H  ; isolate bit 57
    or      eax, ecx                         ; set flags from low |= high
    je      SHORT $LN2@Method1
    and     edx, 536870912      ; 20000000H   ; isolate bit 61
    xor     eax, eax                          ; re-materialize low=0 ?!?
    or      eax, edx                          ; set flags from low |= high
    je      SHORT $LN2@Method1
    mov     eax, 1
    ret     0
$LN2@Method1:
    xor     eax, eax
    ret     0
int Method1(unsigned __int64) ENDP                              ; Method1
```

Obviously this is really stupid materializing a `0` for the low half instead of just ignoring it. MSVC does much better if we change the bitfield member type to `unsigned`. (In the Godbolt link, I changed that to `bf_t` so I could use a typedef separate from UINT64, keeping that for the other union member.)

With a struct based on `unsigned field : 1` bitfield members, MSVC doesn't need the helper at `-Od`

And it even makes better code at `-O2`, so you should definitely do that in your real production code. Only use `uint64_t` or `unsigned long long` members for fields that need to be wider than 32 bits, if you care about performance on MSVC which apparently has a missed-optimization bug with 64-bit types for bitfield members.

```
;; MSVC -O2 with plain  unsigned  (or uint32_t) bitfield members
int Method1(unsigned __int64) PROC                              ; Method1, COMDAT
    mov     eax, DWORD PTR _Data$[esp]
    test    eax, 33554432                     ; 02000000H
    je      SHORT $LN2@Method1
    test    eax, 536870912                    ; 20000000H
    je      SHORT $LN2@Method1
    mov     eax, 1
    ret     0
$LN2@Method1:
    xor     eax, eax
    ret     0
int Method1(unsigned __int64) ENDP…

Unresolved external symbol __aullshr when optimization is turned off

Solution

Problem