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

Hmmm, very interesting. I would think this would apply to _all_ libgcc
functions, but somehow the issue is being avoided. I haven't had a good
look at what libgcc functions are called by U-Boot - have you?

> This change barrows (steals) a technique and some code from coreboot which

s/barrows/borrows/

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

Ah, yes you have - Can you give me a list? I think to be pragmatic we
should either wrap the all or go down the private libgcc path like ARM has
done. Private lib functions would elliminate the overhead, but is this
really such a problem anyway?

Regards,

Graeme