[U-Boot] [PATCH v2] x86: Wrap small helper functions from libgcc to avoid an ABI mismatch

[Graeme Russ]

Hi Gabe,

On Wed, Nov 9, 2011 at 9:34 AM, Gabe Black <gabeblack at chromium.org> wrote:
> When gcc compiles some 64 bit operations on a 32 bit machine, it generates
> calls to small functions instead of instructions which do the job directly.
> Those functions are defined in libgcc and transparently provide whatever
> functionality was necessary. Unfortunately, u-boot can be built with a
> non-standard ABI when libgcc isn't. More specifically, u-boot uses
> -mregparm. When the u-boot and libgcc are linked together, very confusing
> bugs can crop up, for instance seemingly normal integer division or modulus
> getting the wrong answer or even raising a spurious divide by zero
> exception.
>
> This change barrows (steals) a technique and some code from coreboot which
> solves this problem by creating wrappers which translate the calling
> convention when calling the functions in libgcc. Unfortunately that means that
> these instructions which had already been turned into functions have even more
> overhead, but more importantly it makes them work properly.
>
> To find all of the functions that needed wrapping, u-boot was compiled without
> linking in libgcc. All the symbols the linker complained were undefined were
> presumed to be the symbols that are needed from libgcc. These were a subset of
> the symbols covered by the coreboot code, so it was used unmodified.
>
> Signed-off-by: Gabe Black <gabeblack at chromium.org>
> ---
> Changes in v2:
> - Change the [x86] tag to x86:
> - Mention -mregparm in the commit message.
> - Get rid of a stray line which snuck in during a rebase.

As mentioned in a reply to 'Import the glibc memset implementa​tion', I
think I would prefer to either:

 - Investigate if regparm usage can be dropped so U-Boot is ABI compliant
 - If not, use USE_PRIVATE_LIBGCC and implement all required libgcc
   functions in U-Boot

Either way, I don't want to have the possibility that someone uses another
libgcc function, forgets to put a wrapper around it, and encounter 'weird'
bugs

Regards,

Graeme