All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] x86: Wrap small helper functions from libgcc to avoid an ABI mismatch
Date: Wed, 30 Nov 2011 22:03:12 +1100	[thread overview]
Message-ID: <4ED60D70.2000008@gmail.com> (raw)
In-Reply-To: <1321520497-20284-1-git-send-email-gabeblack@chromium.org>

Hi Gabe,

On 17/11/11 20:01, Gabe Black 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 borrows (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.
> 
> To prevent symbols which are provided by libgcc but not currently wrapped
> (or even known about) from being silently linked against by code generated
> by libgcc, a new copy of libgcc is created where all the symbols are
> prefixed with __normal_. Without being purposefully wrapped, these symbols
> will cause linker errors instead of silently introducing very subtle,
> confusing bugs.
> 
> Another approach would be to whitelist symbols from libgcc and strip out
> all the others. The problem with this approach is that it requires the
> white listed symbols to be specified three times, once for objcopy, once so
> the linker inserts the wrapped, and once to generate the wrapper itself,
> while this implementation needs it to be listed only twice. There isn't
> much tangible difference in what each approach produces, so this one was
> preferred.
> 
> Signed-off-by: Gabe Black <gabeblack@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.
> 
> Changes in v3:
> - Prevent symbols from libgcc which aren't wrapped from getting silently
> picked up by the linker.
> 
>  arch/x86/config.mk    |    7 +++++++
>  arch/x86/lib/Makefile |    6 ++++++
>  arch/x86/lib/gcc.c    |   38 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 51 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/lib/gcc.c

Applied to u-boot-x86/master

Thanks,

Graeme

  parent reply	other threads:[~2011-11-30 11:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08  9:27 [U-Boot] [PATCH] [x86] Wrap small helper functions from libgcc to avoid an ABI mismatch Gabe Black
2011-11-08 13:33 ` Mike Frysinger
2011-11-08 22:27   ` Gabe Black
2011-11-08 22:34 ` [U-Boot] [PATCH v2] x86: " Gabe Black
2011-11-08 23:14   ` Graeme Russ
2011-11-09  4:49     ` Mike Frysinger
2011-11-09  3:57       ` Graeme Russ
2011-11-09  5:34         ` Mike Frysinger
2011-11-17  9:01           ` [U-Boot] [PATCH v3] " Gabe Black
2011-11-17  9:13             ` Gabe Black
2011-11-30 11:03             ` Graeme Russ [this message]
2011-11-09  3:05   ` [U-Boot] [PATCH v2] " Graeme Russ
2011-11-09 10:32   ` [U-Boot] [RFC] x86: Do no use reparm as it break libgcc linkage Graeme Russ
2011-11-09 17:12     ` Mike Frysinger
2011-11-09 21:42       ` Graeme Russ
2011-11-10  4:13         ` Mike Frysinger
2011-11-10  4:22           ` Graeme Russ
2011-11-10  5:10             ` Graeme Russ
2011-11-10 17:15             ` Mike Frysinger
2011-11-10 22:53               ` Graeme Russ
2011-11-11  0:23                 ` Mike Frysinger
2011-11-11  1:23                   ` Graeme Russ
2011-11-11  1:40                     ` Mike Frysinger
2011-11-11  1:51                       ` Graeme Russ
2011-11-11  1:55                         ` Mike Frysinger
2011-11-11  1:59                           ` Graeme Russ
2011-11-11  2:10                             ` Gabe Black
2011-11-11  2:22                               ` Graeme Russ
2011-11-11  2:41                                 ` Gabe Black
2011-11-11  4:49                                   ` Graeme Russ
2011-11-11  5:04                                     ` Mike Frysinger
2011-11-11  5:16                                       ` Graeme Russ
2011-11-11 16:24                                         ` Mike Frysinger
2011-11-11  2:44                             ` Mike Frysinger
2011-11-11 19:59                           ` Scott Wood
2011-11-16 23:00     ` Graeme Russ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED60D70.2000008@gmail.com \
    --to=graeme.russ@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.