arm: include: Import unified.h from Linux kernel

Drop the underscore from the filenames of files implementing libgcc routines. There is no functional change. This change is done to make sync with Linux kernel easier.

Signed-off-by Marek Vasut <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Simon Glass <[email protected]>

Cc Tom Rini <[email protected]>

---
 arch/arm/lib/Makefile                    | 6 +++---
 arch/arm/lib/{_ashldi3.S => ashldi3.S}   | 0
 arch/arm/lib/{_ashrdi3.S => ashrdi3.S}   | 0
 arch/arm/lib/{_divsi3.S => divsi3.S}     | 0
 arch/arm/lib/{_lshrdi3.S => lshrdi3.S}   | 0
 arch/arm/lib/{_modsi3.S => modsi3.S}     | 0
 arch/arm/lib/{_udivsi3.S => udivsi3.S}   | 0
 arch/arm/lib/{_uldivmod.S => uldivmod.S} | 0
 arch/arm/lib/{_umodsi3.S => umodsi3.S}   | 0
 9 files changed, 3 insertions(+), 3 deletions(-)

 rename arch/arm/lib/{_ashldi3.S => ashldi3.S} (100%)
 rename arch/arm/lib/{_ashrdi3.S => ashrdi3.S} (100%)
 rename arch/arm/lib/{_divsi3.S => divsi3.S} (100%)
 rename arch/arm/lib/{_lshrdi3.S => lshrdi3.S} (100%)
 rename arch/arm/lib/{_modsi3.S => modsi3.S} (100%)
 rename arch/arm/lib/{_udivsi3.S => udivsi3.S} (100%)
 rename arch/arm/lib/{_uldivmod.S => uldivmod.S} (100%)
 rename arch/arm/lib/{_umodsi3.S => umodsi3.S} (100%)

Sync the libgcc shift operations with Linux kernel 4.4.6 , commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . Syncing these three files is easy, as there is almost no change in them, except the addition of Thumb support.

Signed-off-by Marek Vasut <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Simon Glass <[email protected]>

Cc Tom Rini <[email protected]>

---
 arch/arm/lib/ashldi3.S | 12 ++++++++----
 arch/arm/lib/ashrdi3.S | 12 ++++++++----
 arch/arm/lib/lshrdi3.S | 12 ++++++++----
 3 files changed, 24 insertions(+), 12 deletions(-)

Sync the libgcc 32bit division and modulo operations with Linux 4.4.6 , commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . The functions in these four files are present in lib1funcs.S in Linux, so replace these files with lib1funcs.S from Linux.

Since we do not support stack unwinding, instead of importing the whole asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro in lib1funcs.S . Moreover, to make all of the functions available, define CONFIG_AEABI , which is safe, because U-Boot is always compiled with ARM EABI.

Signed-off-by Marek Vasut <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Simon Glass <[email protected]>

Cc Tom Rini <[email protected]>

---
 arch/arm/lib/Makefile    |   5 +-
 arch/arm/lib/divsi3.S    | 143 -------------------
 arch/arm/lib/lib1funcs.S | 351 +++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/lib/modsi3.S    |  99 -------------
 arch/arm/lib/udivsi3.S   |  95 -------------
 arch/arm/lib/umodsi3.S   |  90 ------------
 6 files changed, 353 insertions(+), 430 deletions(-)
 delete mode 100644 arch/arm/lib/divsi3.S
 create mode 100644 arch/arm/lib/lib1funcs.S
 delete mode 100644 arch/arm/lib/modsi3.S
 delete mode 100644 arch/arm/lib/udivsi3.S
 delete mode 100644 arch/arm/lib/umodsi3.S

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

Also, libgcc is not a standalone project that can be frozen, forked or improved freely; it is an internal component of the GCC toolchain. No standard defines what libgcc is or should be, and we have no control over the 'contract' between GCC-emitted code and libgcc. The GCC project may decide to change that contract at any time, and produce a new toolchain and a new libgcc. Using our private libgcc by default will cause all targets to break for no good reason. We've already been bitten by internal GCC changes on which we were dependent; adding more such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our targets due to its libgcc, then we should not only "snapshot and fix" libgcc; we should "snapshot and fix" the whole GCC toolchain, to make sure we keep a consistent copy of it. I don't think that would be a viable move.

And if we don't believe that GCC is generally unable to properly build U-Boot, then we should always use it as provided unless it is provably buggy, in which case if a private libgcc is a fix, then by all means we should use it.

And whenever we find that a GCC toolchain is provably buggy, we should raise a bug, either to the toolchain provider if the issue is only with a given binary release (e.g. mismatched or badly supported endianness), or to the GCC project if the bug is inherent to GCC (e.g. generation of non-supported opcodes for a given arch/cpu).

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 21 lines

Also, libgcc is not a standalone project that can be frozen, forked or improved freely; it is an internal component of the GCC toolchain. No standard defines what libgcc is or should be, and we have no control over the 'contract' between GCC-emitted code and libgcc. The GCC project may decide to change that contract at any time, and produce a new toolchain and a new libgcc. Using our private libgcc by default will cause all targets to break for no good reason. We've already been bitten by internal GCC changes on which we were dependent; adding more such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our targets due to its libgcc, then we should not only "snapshot and fix" libgcc; we should "snapshot and fix" the whole GCC toolchain, to make sure we keep a consistent copy of it. I don't think that would be a viable move.

And if we don't believe that GCC is generally unable to properly build U-Boot, then we should always use it as provided unless it is provably buggy, in which case if a private libgcc is a fix, then by all means we should use it.

Quoted 5 lines

And whenever we find that a GCC toolchain is provably buggy, we should raise a bug, either to the toolchain provider if the issue is only with a given binary release (e.g. mismatched or badly supported endianness), or to the GCC project if the bug is inherent to GCC (e.g. generation of non-supported opcodes for a given arch/cpu).

Ah, but this shows part of the problem. We don't need "libgcc" as in "the thing which provides gcc'isms". We need "libgcc" as in "the thing which provides AEABI functions".

Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or simply aren't available (again, clang). So I am in favour of re-syncing with this part of the kernel and mirroring the decision to always include these functions, again, like the kernel does.

Signature · 1 line

Tom

Hello Tom,

Quoted 28 lines · Tom Rini

Quoted 26 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

Quoted 4 lines

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

You mean clang does not produce self-sustained binaries?

Quoted 27 lines

Quoted 26 lines

Also, libgcc is not a standalone project that can be frozen, forked or improved freely; it is an internal component of the GCC toolchain. No standard defines what libgcc is or should be, and we have no control over the 'contract' between GCC-emitted code and libgcc. The GCC project may decide to change that contract at any time, and produce a new toolchain and a new libgcc. Using our private libgcc by default will cause all targets to break for no good reason. We've already been bitten by internal GCC changes on which we were dependent; adding more such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our targets due to its libgcc, then we should not only "snapshot and fix" libgcc; we should "snapshot and fix" the whole GCC toolchain, to make sure we keep a consistent copy of it. I don't think that would be a viable move.

And if we don't believe that GCC is generally unable to properly build U-Boot, then we should always use it as provided unless it is provably buggy, in which case if a private libgcc is a fix, then by all means we should use it.

And whenever we find that a GCC toolchain is provably buggy, we should raise a bug, either to the toolchain provider if the issue is only with a given binary release (e.g. mismatched or badly supported endianness), or to the GCC project if the bug is inherent to GCC (e.g. generation of non-supported opcodes for a given arch/cpu).

Quoted 3 lines

Ah, but this shows part of the problem. We don't need "libgcc" as in "the thing which provides gcc'isms". We need "libgcc" as in "the thing which provides AEABI functions".

Not sure I'm getting what you mean. For one thing, I don't see that AEABI specifies any functions. Also, I don't see where it is established that U-Boot "needs AEABI functions". Finally, I don't see that libgcc is a standalone project aiming at providing AEABI functions.

Quoted 5 lines

Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or simply aren't available (again, clang). So I am in favour of re-syncing with this part of the kernel and mirroring the decision to always include these functions, again, like the kernel does.

If we are using libgcc for providing AEABI services then we are using it wrong. Its role is to support GCC-generated code.

Could you give me an example of this "need for [an] AEABI function"?

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 47 lines · Sergey Kubushyn

Quoted 44 lines · Tom Rini

Quoted 31 lines · Albert ARIBAUD

Hello Tom,

Quoted 28 lines · Tom Rini

Quoted 26 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

Quoted 6 lines

Quoted 4 lines

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

Quoted 47 lines · Sergey Kubushyn

Quoted 44 lines · Tom Rini

Quoted 31 lines · Albert ARIBAUD

Hello Tom,

Quoted 28 lines · Tom Rini

Quoted 26 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

Quoted 6 lines

Quoted 4 lines

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

Quoted 52 lines · Tom Rini

Quoted 50 lines · Sergey Kubushyn

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 3 lines

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

Quoted 75 lines · Marek Vasut

Quoted 74 lines · Tom Rini

Quoted 72 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 7 lines

Quoted 3 lines

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64() function that is used by do_div() from include/asm/div64.h for 32-bit ARM platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h (that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

Quoted 85 lines · Sergey Kubushyn

Quoted 75 lines · Marek Vasut

Quoted 74 lines · Tom Rini

Quoted 72 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 7 lines

Quoted 3 lines

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

Quoted 7 lines

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64() function that is used by do_div() from include/asm/div64.h for 32-bit ARM platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h (that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?

Quoted 100 lines · Marek Vasut

Quoted 98 lines · Sergey Kubushyn

Quoted 77 lines · Marek Vasut

Quoted 76 lines · Tom Rini

Quoted 74 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 8 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 8 lines

Quoted 4 lines

Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

Quoted 5 lines

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?

Sure I'll test it, no problems. Just bake the patch :)

Quoted 106 lines · Sergey Kubushyn

Quoted 104 lines · Marek Vasut

Quoted 88 lines · Sergey Kubushyn

Quoted 77 lines · Marek Vasut

Quoted 76 lines · Tom Rini

Quoted 74 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 8 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 8 lines

Quoted 4 lines

Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

Quoted 10 lines

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

Quoted 3 lines

Quoted 1 line

What do you think? I can bake a patch real quick, so you can test it ?

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

Quoted 106 lines · Sergey Kubushyn

Quoted 104 lines · Marek Vasut

Quoted 88 lines · Sergey Kubushyn

Quoted 77 lines · Marek Vasut

Quoted 76 lines · Tom Rini

Quoted 74 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 8 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 8 lines

Quoted 4 lines

Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

Quoted 10 lines

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

Quoted 3 lines

Quoted 1 line

What do you think? I can bake a patch real quick, so you can test it ?

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

Quoted 143 lines · Marek Vasut

Quoted 142 lines · Sergey Kubushyn

Quoted 140 lines · Marek Vasut

Quoted 120 lines · Sergey Kubushyn

Quoted 112 lines · Marek Vasut

Quoted 104 lines · Tom Rini

Quoted 96 lines · Sergey Kubushyn

Quoted 85 lines · Tom Rini

Quoted 81 lines · Albert ARIBAUD

Hello Tom,

Quoted 65 lines · Tom Rini

Quoted 48 lines · Albert ARIBAUD

Hello Marek,

Quoted 39 lines · Marek Vasut

This patch decouples U-Boot binary from the
toolchain on
systems where
private libgcc is available. Instead of pulling in
functions
provided
by the libgcc from the toolchain, U-Boot will use
it's own set
of libgcc
functions. These functions are usually imported from
Linux
kernel, which
also uses it's own libgcc functions instead of the
ones
provided by the
toolchain.

This patch solves a rather common problem. The
toolchain can
usually
generate code for many variants of target
architecture and
often even
different endianness. The libgcc on the other hand
is usually
compiled
for one particular configuration and the functions
provided by
it may
or may not be suited for use in U-Boot. This can
manifest in
two ways,
either the U-Boot fails to compile altogether and
linker will
complain
or, in the much worse case, the resulting U-Boot
will build,
but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 14 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.

Quoted 10 lines

This isn't true, exactly. If using clang for example everyone
needs to
enable this code. We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain. And
we get
that.

Quoted 1 line

You mean clang does not produce self-sustained binaries?

Quoted 8 lines

clang does not provide "libgcc", so there's no -lgcc providing
all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 6 lines

There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 6 lines

Well, this is an example of why we both don't want libgcc ever nor
do we
want to overly expand what we do offer. In this case isn't it an
example of something that should be using lldiv/do_div/etc?

Quoted 5 lines

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?

Quoted 13 lines

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

What do you think? I can bake a patch real quick, so you can test it ?

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm analyzing it right now, will come up with more later today.

Quoted 133 lines · Sergey Kubushyn

Quoted 131 lines · Marek Vasut

Quoted 5 lines · Sergey Kubushyn

Quoted 4 lines · Marek Vasut

Quoted 4 lines · Sergey Kubushyn

Quoted 2 lines · Marek Vasut

Quoted 2 lines

Quoted 1 line

Quoted 1 line · Tom Rini

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines · Tom Rini

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Quoted 2 lines · Albert ARIBAUD > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Tom,

Quoted 1 line

Quoted 1 line

On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > > <[email protected]>

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line · wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

Quoted 2 lines · ARIBAUD > > > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Marek,
On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > > <[email protected]>

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

wrote:
This patch decouples U-Boot binary from the >
toolchain on
systems where
private libgcc is available. Instead of

pulling in > > > > > > > > > > > functions

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided
by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > > it's own set

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

of libgcc
functions. These functions are usually

imported from > > > > > > > > > > > Linux

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

kernel, which
also uses it's own libgcc functions instead of

the > > > > > > > > > > > ones

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

provided by the
toolchain.
This patch solves a

rather common problem. The > > > > > > > > > > > toolchain can

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

usually
generate code for many variants of target > >

architecture and

Quoted 2 lines

often even
different endianness. The libgcc on the other

hand > > > > > > > > > > > is usually

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

compiled
for one particular configuration and the

functions > > > > > > > > > > > provided by

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

it may
or may not be suited for use in U-Boot. This

can > > > > > > > > > > > manifest in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

two ways,
either the U-Boot fails to compile altogether

and > > > > > > > > > > > linker will

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

complain
or, in the much worse case, the resulting

U-Boot > > > > > > > > > > > will build,

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

but will
misbehave in very subtle and hard to debug ways.
I don't think using private

libgcc by default is a > > > > > > > > > > good idea.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > > but a fix

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for some
cases where a target cannot properly link with

the > > > > > > > > > > libgcc

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided by
the (specific release of the) GCC toolchain in

use. > > > > > > > > > > Using

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

private libgcc
to other cases than these does not fix or

improve > > > > > > > > > > anything; those

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

other cases were working and did not require any

fix > > > > > > > > > > in this

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

respect.
This isn't true, exactly. If

using clang for example > > > > > > > > > everyone

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 2 lines

needs to
enable this code. We're also using -fno-builtin >

-ffreestanding

Quoted 2 lines

which
should limit the amount of interference from the >

toolchain. And

Quoted 3 lines

we get
that.

Quoted 1 line

You mean clang does not produce

self-sustained binaries?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

clang does not provide "libgcc", so

there's no -lgcc > > > > > > > providing

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > > division

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Well, this is an example of why we both don't

want libgcc ever > > > > > nor

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

do we
want to overly expand what we do offer. In this case

isn't it > > > > > an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

example of something that should be using lldiv/do_div/etc?

Quoted 1 line

Quoted 1 line

Quoted 1 line

I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > > copy

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

also doesn't implement the function. Which toolchain do you

use > > > > and

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

which target did you compile?

Quoted 1 line

Quoted 1 line

I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > > float.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_

have

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

div64.h
(that is totally different from what Linux provides) but no

div64.S > > > in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

arch/arm/lib.

Quoted 1 line

In that case, we should just import div64.S from Linux on

arm32 and be

Quoted 1 line

Quoted 1 line

done with it ? Since we now have all the necessary macros thanks

to > > the

Quoted 1 line

Quoted 1 line

first four patches in this series, that should be trivial.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

What do you think? I can bake a patch real quick, so you can

test it ?

Quoted 1 line

Quoted 1 line

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm analyzing it right now, will come up with more later today.

OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc, my bad -- thought it would be automatic. Having that defined makes build fail complaining about assembly syntax in div64.S:

=== Cut ===
arch/arm/lib/div64.S: Assembler messages:
arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl ip)'
arch/arm/lib/div64.S:186: Error: bad instruction thumb( lsl r1,r1,ip)' arch/arm/lib/div64.S:187: Error: bad instruction thumb( orr r2,r2,r1)' scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed make[1]: *** [arch/arm/lib/div64.o] Error 1
Makefile:1214: recipe for target 'arch/arm/lib' failed
make: *** [arch/arm/lib] Error 2
=== Cut ===

Probably something is missing in div64.h? The Linux one is totally different. Digging in right now...

Quoted 160 lines · Sergey Kubushyn

Quoted 133 lines · Sergey Kubushyn

Quoted 131 lines · Marek Vasut

Quoted 5 lines · Sergey Kubushyn

Quoted 4 lines · Marek Vasut

Quoted 4 lines · Sergey Kubushyn

Quoted 2 lines · Marek Vasut

Quoted 2 lines

Quoted 1 line

Quoted 1 line · Tom Rini

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines · Tom Rini

Quoted 1 line

Quoted 1 line

Quoted 1 line

On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Quoted 2 lines · Albert ARIBAUD > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Tom,

Quoted 1 line

On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > > <[email protected]>

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line · wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

Quoted 2 lines · ARIBAUD > > > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Marek,
On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > > <[email protected]>

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

wrote:
This patch decouples U-Boot binary from the >
toolchain on
systems where
private libgcc is available. Instead of

pulling in > > > > > > > > > > > functions

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided
by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > > it's own set

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

of libgcc
functions. These functions are usually

imported from > > > > > > > > > > > Linux

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

kernel, which
also uses it's own libgcc functions instead of

the > > > > > > > > > > > ones

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

provided by the
toolchain.
This patch solves a

rather common problem. The > > > > > > > > > > > toolchain can

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

usually
generate code for many variants of target > >
architecture and
often even
different endianness. The libgcc on the other

hand > > > > > > > > > > > is usually

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

compiled
for one particular configuration and the

functions > > > > > > > > > > > provided by

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

it may
or may not be suited for use in U-Boot. This

can > > > > > > > > > > > manifest in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

two ways,
either the U-Boot fails to compile altogether

and > > > > > > > > > > > linker will

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

complain
or, in the much worse case, the resulting

U-Boot > > > > > > > > > > > will build,

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

but will
misbehave in very subtle and hard to debug ways.
I don't think using private

libgcc by default is a > > > > > > > > > > good idea.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > > but a fix

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for some
cases where a target cannot properly link with

the > > > > > > > > > > libgcc

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided by
the (specific release of the) GCC toolchain in

use. > > > > > > > > > > Using

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

private libgcc
to other cases than these does not fix or

improve > > > > > > > > > > anything; those

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

other cases were working and did not require any

fix > > > > > > > > > > in this

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

respect.
This isn't true, exactly. If

using clang for example > > > > > > > > > everyone

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 2 lines

needs to
enable this code. We're also using -fno-builtin >

-ffreestanding

Quoted 2 lines

which
should limit the amount of interference from the >

toolchain. And

Quoted 3 lines

we get
that.
You mean clang does not produce

self-sustained binaries?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

clang does not provide "libgcc", so

there's no -lgcc > > > > > > > providing

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > > division

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Well, this is an example of why we both don't

want libgcc ever > > > > > nor

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

do we
want to overly expand what we do offer. In this case

isn't it > > > > > an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

example of something that should be using lldiv/do_div/etc?

Quoted 1 line

Quoted 1 line

Quoted 1 line

I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > > copy

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

also doesn't implement the function. Which toolchain do you

use > > > > and

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

which target did you compile?

Quoted 1 line

Quoted 1 line

I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > > float.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_

have

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

div64.h
(that is totally different from what Linux provides) but no

div64.S > > > in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

arch/arm/lib.

Quoted 1 line

In that case, we should just import div64.S from Linux on

arm32 and be

Quoted 1 line

Quoted 1 line

done with it ? Since we now have all the necessary macros thanks

to > > the

Quoted 1 line

Quoted 1 line

first four patches in this series, that should be trivial.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

What do you think? I can bake a patch real quick, so you can

test it ?

Quoted 1 line

Quoted 1 line

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm analyzing it right now, will come up with more later today.

OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc, my bad -- thought it would be automatic. Having that defined makes build fail complaining about assembly syntax in div64.S:

=== Cut ===
arch/arm/lib/div64.S: Assembler messages:
arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl ip)'
arch/arm/lib/div64.S:186: Error: bad instruction thumb( lsl r1,r1,ip)' arch/arm/lib/div64.S:187: Error: bad instruction thumb( orr r2,r2,r1)' scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed make[1]: *** [arch/arm/lib/div64.o] Error 1
Makefile:1214: recipe for target 'arch/arm/lib' failed
make: *** [arch/arm/lib] Error 2
=== Cut ===

Quoted 2 lines

Probably something is missing in div64.h? The Linux one is totally different. Digging in right now...

Are you building the stuff with all of these 5+1 patches ?

Quoted 167 lines · Marek Vasut

Quoted 165 lines · Sergey Kubushyn

Quoted 134 lines · Sergey Kubushyn

Quoted 132 lines · Marek Vasut

Quoted 5 lines · Sergey Kubushyn

Quoted 4 lines · Marek Vasut

Quoted 4 lines · Sergey Kubushyn

Quoted 2 lines · Marek Vasut

Quoted 2 lines

Quoted 1 line

Quoted 1 line · Tom Rini

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines · Tom Rini

Quoted 1 line

Quoted 1 line

On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Quoted 2 lines · Albert ARIBAUD > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Tom,
On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > > <[email protected]>

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

wrote:
On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

Quoted 2 lines · ARIBAUD > > > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Marek,
On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > > <[email protected]>

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

wrote:
This patch decouples U-Boot binary from the >
toolchain on
systems where
private libgcc is available. Instead of

pulling in > > > > > > > > > > > functions

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided
by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > > it's own set

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

of libgcc
functions. These functions are usually

imported from > > > > > > > > > > > Linux

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

kernel, which
also uses it's own libgcc functions instead of

the > > > > > > > > > > > ones

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

provided by the
toolchain.
This patch solves a

rather common problem. The > > > > > > > > > > > toolchain can

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

usually
generate code for many variants of target > >
architecture and
often even
different endianness. The libgcc on the other

hand > > > > > > > > > > > is usually

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

compiled
for one particular configuration and the

functions > > > > > > > > > > > provided by

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

it may
or may not be suited for use in U-Boot. This

can > > > > > > > > > > > manifest in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

two ways,
either the U-Boot fails to compile altogether

and > > > > > > > > > > > linker will

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

complain
or, in the much worse case, the resulting

U-Boot > > > > > > > > > > > will build,

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

but will
misbehave in very subtle and hard to debug ways.
I don't think using private

libgcc by default is a > > > > > > > > > > good idea.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > > but a fix

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for some
cases where a target cannot properly link with

the > > > > > > > > > > libgcc

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided by
the (specific release of the) GCC toolchain in

use. > > > > > > > > > > Using

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

private libgcc
to other cases than these does not fix or

improve > > > > > > > > > > anything; those

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

other cases were working and did not require any

fix > > > > > > > > > > in this

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

respect.
This isn't true, exactly. If

using clang for example > > > > > > > > > everyone

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

needs to
enable this code. We're also using -fno-builtin >
-ffreestanding
which
should limit the amount of interference from the >
toolchain. And
we get
that.
You mean clang does not produce

self-sustained binaries?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

clang does not provide "libgcc", so

there's no -lgcc > > > > > > > providing

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > > division

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 1 line

Quoted 1 line

Well, this is an example of why we both don't

want libgcc ever > > > > > nor

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

do we
want to overly expand what we do offer. In this case

isn't it > > > > > an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

example of something that should be using lldiv/do_div/etc?

Quoted 1 line

Quoted 1 line

Quoted 1 line

I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > > copy

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

also doesn't implement the function. Which toolchain do you

use > > > > and

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

which target did you compile?

Quoted 1 line

Quoted 1 line

I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > > float.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_

have

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

div64.h
(that is totally different from what Linux provides) but no

div64.S > > > in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

arch/arm/lib.

Quoted 1 line

In that case, we should just import div64.S from Linux on

arm32 and be

Quoted 1 line

Quoted 1 line

done with it ? Since we now have all the necessary macros thanks

to > > the

Quoted 2 lines

Quoted 2 lines

first four patches in this series, that should be trivial.

Quoted 1 line

Quoted 1 line

What do you think? I can bake a patch real quick, so you can

Quoted 8 lines

Quoted 4 lines

test it ?

Quoted 1 line

Quoted 1 line

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.

OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
my bad -- thought it would be automatic. Having that defined makes build fail complaining about assembly syntax in div64.S:

=== Cut ===
arch/arm/lib/div64.S: Assembler messages:
arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl ip)'
arch/arm/lib/div64.S:186: Error: bad instruction thumb( lsl r1,r1,ip)' arch/arm/lib/div64.S:187: Error: bad instruction thumb( orr r2,r2,r1)' scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed
make[1]: *** [arch/arm/lib/div64.o] Error 1
Makefile:1214: recipe for target 'arch/arm/lib' failed
make: *** [arch/arm/lib] Error 2
=== Cut ===

Probably something is missing in div64.h? The Linux one is totally different. Digging in right now...

Quoted 1 line

Are you building the stuff with all of these 5+1 patches ?

Nope. Aren't those already in U-Boot master? I pulled the latest master and thought those were there. If not would you please send me those 5 patches so
I wouldn't have to hunt them through archives?

Quoted 169 lines · Sergey Kubushyn

Quoted 167 lines · Marek Vasut

Quoted 165 lines · Sergey Kubushyn

Quoted 134 lines · Sergey Kubushyn

Quoted 132 lines · Marek Vasut

Quoted 5 lines · Sergey Kubushyn

Quoted 4 lines · Marek Vasut

Quoted 4 lines · Sergey Kubushyn

Quoted 2 lines · Marek Vasut

Quoted 2 lines

Quoted 1 line

Quoted 1 line · Tom Rini

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines · Tom Rini

Quoted 1 line

On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Quoted 2 lines · Albert ARIBAUD > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Tom,
On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > > <[email protected]>

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

wrote:
On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

Quoted 2 lines · ARIBAUD > > > > > > > > > wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Hello Marek,
On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > > <[email protected]>

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

wrote:
This patch decouples U-Boot binary from the >
toolchain on
systems where
private libgcc is available. Instead of

pulling in > > > > > > > > > > > functions

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided
by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > > it's own set

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

of libgcc
functions. These functions are usually

imported from > > > > > > > > > > > Linux

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

kernel, which
also uses it's own libgcc functions instead of

the > > > > > > > > > > > ones

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

provided by the
toolchain.
This patch solves a

rather common problem. The > > > > > > > > > > > toolchain can

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

usually
generate code for many variants of target > >
architecture and
often even
different endianness. The libgcc on the other

hand > > > > > > > > > > > is usually

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

compiled
for one particular configuration and the

functions > > > > > > > > > > > provided by

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

it may
or may not be suited for use in U-Boot. This

can > > > > > > > > > > > manifest in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

two ways,
either the U-Boot fails to compile altogether

and > > > > > > > > > > > linker will

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

complain
or, in the much worse case, the resulting

U-Boot > > > > > > > > > > > will build,

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

but will
misbehave in very subtle and hard to debug ways.
I don't think using private

libgcc by default is a > > > > > > > > > > good idea.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > > but a fix

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

for some
cases where a target cannot properly link with

the > > > > > > > > > > libgcc

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

provided by
the (specific release of the) GCC toolchain in

use. > > > > > > > > > > Using

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

private libgcc
to other cases than these does not fix or

improve > > > > > > > > > > anything; those

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

other cases were working and did not require any

fix > > > > > > > > > > in this

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

respect.
This isn't true, exactly. If

using clang for example > > > > > > > > > everyone

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

needs to
enable this code. We're also using -fno-builtin >
-ffreestanding
which
should limit the amount of interference from the >
toolchain. And
we get
that.
You mean clang does not produce

self-sustained binaries?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

clang does not provide "libgcc", so

there's no -lgcc > > > > > > > providing

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S
_udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > > division

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 1 line

Well, this is an example of why we both don't

want libgcc ever > > > > > nor

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

do we
want to overly expand what we do offer. In this case

isn't it > > > > > an

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

example of something that should be using lldiv/do_div/etc?

Quoted 1 line

Quoted 1 line

I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > > copy

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

also doesn't implement the function. Which toolchain do you

use > > > > and

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

which target did you compile?

Quoted 1 line

Quoted 1 line

I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > > float.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_

have

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

div64.h
(that is totally different from what Linux provides) but no

div64.S > > > in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

arch/arm/lib.

Quoted 1 line

In that case, we should just import div64.S from Linux on

arm32 and be

Quoted 1 line

Quoted 1 line

done with it ? Since we now have all the necessary macros thanks

to > > the

Quoted 2 lines

Quoted 2 lines

first four patches in this series, that should be trivial.

Quoted 1 line

Quoted 1 line

What do you think? I can bake a patch real quick, so you can

Quoted 8 lines

Quoted 4 lines

test it ?

Quoted 1 line

Quoted 1 line

Sure I'll test it, no problems. Just bake the patch :)

Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.

OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
my bad -- thought it would be automatic. Having that defined makes build fail complaining about assembly syntax in div64.S:

=== Cut ===
arch/arm/lib/div64.S: Assembler messages:
arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl ip)'
arch/arm/lib/div64.S:186: Error: bad instruction thumb( lsl r1,r1,ip)' arch/arm/lib/div64.S:187: Error: bad instruction thumb( orr r2,r2,r1)' scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed
make[1]: *** [arch/arm/lib/div64.o] Error 1
Makefile:1214: recipe for target 'arch/arm/lib' failed
make: *** [arch/arm/lib] Error 2
=== Cut ===

Probably something is missing in div64.h? The Linux one is totally different. Digging in right now...

Quoted 6 lines

Quoted 1 line

Are you building the stuff with all of these 5+1 patches ?

Nope. Aren't those already in U-Boot master? I pulled the latest master and thought those were there. If not would you please send me those 5 patches so
I wouldn't have to hunt them through archives?

I'll send you all six off-list.

Quoted 85 lines · Sergey Kubushyn

Quoted 75 lines · Marek Vasut

Quoted 74 lines · Tom Rini

Quoted 72 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 7 lines

Quoted 3 lines

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

Quoted 7 lines

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64() function that is used by do_div() from include/asm/div64.h for 32-bit ARM platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h (that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?

Quoted 94 lines · Marek Vasut

Quoted 92 lines · Sergey Kubushyn

Quoted 75 lines · Marek Vasut

Quoted 74 lines · Tom Rini

Quoted 72 lines · Sergey Kubushyn

Quoted 58 lines · Tom Rini

Quoted 57 lines · Albert ARIBAUD

Hello Tom,

Quoted 52 lines · Tom Rini

Quoted 34 lines · Albert ARIBAUD

Hello Marek,

Quoted 12 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

Quoted 15 lines

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

I don't think using private libgcc by default is a good idea.

Quoted 9 lines

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for video, e.g. from drivers/video/ipu_common.c for i.MX6.

Quoted 7 lines

Quoted 3 lines

Well, this is an example of why we both don't want libgcc ever nor do we want to overly expand what we do offer. In this case isn't it an example of something that should be using lldiv/do_div/etc?

I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy also doesn't implement the function. Which toolchain do you use and which target did you compile?

I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64() function that is used by do_div() from include/asm/div64.h for 32-bit ARM platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h (that is totally different from what Linux provides) but no div64.S in arch/arm/lib.

Quoted 5 lines

In that case, we should just import div64.S from Linux on arm32 and be done with it ? Since we now have all the necessary macros thanks to the first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?

Follow-up _series_ to re-sync our 64bit math stuff with the kernel.

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 27 lines

Quoted 27 lines

Quoted 26 lines

Also, libgcc is not a standalone project that can be frozen, forked or improved freely; it is an internal component of the GCC toolchain. No standard defines what libgcc is or should be, and we have no control over the 'contract' between GCC-emitted code and libgcc. The GCC project may decide to change that contract at any time, and produce a new toolchain and a new libgcc. Using our private libgcc by default will cause all targets to break for no good reason. We've already been bitten by internal GCC changes on which we were dependent; adding more such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our targets due to its libgcc, then we should not only "snapshot and fix" libgcc; we should "snapshot and fix" the whole GCC toolchain, to make sure we keep a consistent copy of it. I don't think that would be a viable move.

And if we don't believe that GCC is generally unable to properly build U-Boot, then we should always use it as provided unless it is provably buggy, in which case if a private libgcc is a fix, then by all means we should use it.

And whenever we find that a GCC toolchain is provably buggy, we should raise a bug, either to the toolchain provider if the issue is only with a given binary release (e.g. mismatched or badly supported endianness), or to the GCC project if the bug is inherent to GCC (e.g. generation of non-supported opcodes for a given arch/cpu).

Quoted 8 lines

Quoted 3 lines

Ah, but this shows part of the problem. We don't need "libgcc" as in "the thing which provides gcc'isms". We need "libgcc" as in "the thing which provides AEABI functions".

Not sure I'm getting what you mean. For one thing, I don't see that AEABI specifies any functions. Also, I don't see where it is established that U-Boot "needs AEABI functions". Finally, I don't see that libgcc is a standalone project aiming at providing AEABI functions.

Well, lets unpack things in the order that it matters. If we kludge the toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start failing on:

arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
undefined reference to `__aeabi_uidiv' /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
undefined reference to `__aeabi_uidiv' /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:66:
undefined reference to `__aeabi_uidiv'
and fail on and on from there (I see several pages). Line 64-66 are:

        printf("CPU clock:        %uMHz\n", get_hclk_pll_rate() / 1000000);
        printf("AHB bus clock:    %uMHz\n", get_hclk_clk_rate() / 1000000);
        printf("Peripheral clock: %uMHz\n", get_periph_clk_rate() / 1000000);

So, despite being "freestanding" and requring "no builtins" we still requiring the toolchain to give us these functions separately, or just bring them ourself. Note that ARC, SH and MIPS all always follow the kernel model of just providing these bits of functionality rather than rely on getting just those things from libgcc.

Quoted 6 lines

Quoted 5 lines

Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or simply aren't available (again, clang). So I am in favour of re-syncing with this part of the kernel and mirroring the decision to always include these functions, again, like the kernel does.

Quoted 4 lines

If we are using libgcc for providing AEABI services then we are using it wrong. Its role is to support GCC-generated code.

Could you give me an example of this "need for [an] AEABI function"?

See above. And yes, we're using libgcc wrong by IMHO using it at all.

We don't need it and opt out of it for almost everything, except for the above.

Signature · 1 line

Tom

Hello Tom,

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)

Quoted 48 lines · Albert ARIBAUD

Hello Tom,

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)

No. For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library. We are entirely in our right to do either of (a) use the compiler-provided library (b) provide our own implementation of what we need. The kernel opts for (b) and I would like us to follow that as well, consistently, rather than ad-hoc.

On Thu, 24 Mar 2016, Tom Rini wrote:

U-Boot is a standalone program not supposed to coexist with any external applications i.e. it is totally self-sufficient, not living in some kind of system environment so it makes perfect sense for it not to use _ANY_ external parts in the final binary.

Quoted 48 lines · Albert ARIBAUD

Hello Tom,

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)

No. For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library. We are entirely in our right to do either of (a) use the compiler-provided library (b) provide our own implementation of what we need. The kernel opts for (b) and I would like us to follow that as well, consistently, rather than ad-hoc.

Signature · 1 line

Tom

Hello Tom,

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

1) GCC keeps its somewhat stable but uncontrolled internal "generated code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc, i.e. whatever ibgcc-related but non-AEABI-related changes occur in a GCC release, we won't break them changes in non-AEABI ;

3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI breakages happen in a given GCC toolchain will not break U-Boot.

4) This design works with any ARM toolchain -- which is kind of evident since it separates generic ARM EABI support from specific toolchain support.

Hello Tom,

Quoted 53 lines · Tom Rini

Quoted 48 lines · Albert ARIBAUD

Hello Tom,

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)

Quoted 6 lines

No. For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library. We are entirely in our right to do either of (a) use the compiler-provided library (b) provide our own implementation of what we need. The kernel opts for (b) and I would like us to follow that as well, consistently, rather than ad-hoc.

Kk, so you did not mean "whatever happens to be aeabi in libgcc, you meant AEABI itself.

But then what you seek is is not a custom libgcc; it is controlled AEABI support library.

I'm fine with that, since, contrary to libgcc, it has an external, stable, definition.

But that is *unrelated* to libgcc, which is not described nor intended as "AEABI support" -- libgcc exists in all architectures, even non-ARM, and provides AEABI in the ARM case by accident -- or, more to the point, by sub-optimal design IMO.

The right design for solving the problems raised by Marek is therefore to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library" and link U-Boot *first* against this AEABI support library, *then* against GCC's libgcc.

Essentially, this 'hijacks' whatever is AEABI from libgcc while not interfering with what is not AEABI (i.e. what is purely GCC/libgcc internals).

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

1) GCC keeps its somewhat stable but uncontrolled internal "generated code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc, i.e. whatever ibgcc-related but non-AEABI-related changes occur in a GCC release, we won't break them changes in non-AEABI ;

3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI breakages happen in a given GCC toolchain will not break U-Boot.

4) This design works with any ARM toolchain -- which is kind of evident since it separates generic ARM EABI support from specific toolchain support.

Quoted 66 lines · Albert ARIBAUD

Hello Tom,

Quoted 53 lines · Tom Rini

Quoted 48 lines · Albert ARIBAUD

Hello Tom,

Quoted 37 lines · Tom Rini

Quoted 36 lines · Albert ARIBAUD

Hello Tom,

Quoted 32 lines · Tom Rini

Quoted 19 lines · Albert ARIBAUD

Hello Marek,

Quoted 7 lines · Marek Vasut

This patch decouples U-Boot binary from the toolchain on systems where private libgcc is available. Instead of pulling in functions provided by the libgcc from the toolchain, U-Boot will use it's own set of libgcc functions. These functions are usually imported from Linux kernel, which also uses it's own libgcc functions instead of the ones provided by the toolchain.

Quoted 8 lines

This patch solves a rather common problem. The toolchain can usually generate code for many variants of target architecture and often even different endianness. The libgcc on the other hand is usually compiled for one particular configuration and the functions provided by it may or may not be suited for use in U-Boot. This can manifest in two ways, either the U-Boot fails to compile altogether and linker will complain or, in the much worse case, the resulting U-Boot will build, but will misbehave in very subtle and hard to debug ways.

Quoted 7 lines

I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.

This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.

Quoted 7 lines

Quoted 1 line

You mean clang does not produce self-sustained binaries?

clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx

Quoted 3 lines

(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)

Quoted 6 lines

No. For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library. We are entirely in our right to do either of (a) use the compiler-provided library (b) provide our own implementation of what we need. The kernel opts for (b) and I would like us to follow that as well, consistently, rather than ad-hoc.

Kk, so you did not mean "whatever happens to be aeabi in libgcc, you meant AEABI itself.

Quoted 2 lines

But then what you seek is is not a custom libgcc; it is controlled AEABI support library.

No. It's not libgcc. We call it libgcc, but we shouldn't. We should call it lib1funcs which is part of the end result of Marek's patches. LLVM has its own library which does this. But it's not about LLVM, either.

Quoted 7 lines

I'm fine with that, since, contrary to libgcc, it has an external, stable, definition.

But that is *unrelated* to libgcc, which is not described nor intended as "AEABI support" -- libgcc exists in all architectures, even non-ARM, and provides AEABI in the ARM case by accident -- or, more to the point, by sub-optimal design IMO.

Yes, "libgcc" often, but not always, is how U-Boot provides the architecture specific compiler support library functions. Or rather, ARM and PowerPC are the big cases where we rely on -lgcc and everywhere else simply provides the required functionality in U-Boot.

Quoted 8 lines

The right design for solving the problems raised by Marek is therefore to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library" and link U-Boot *first* against this AEABI support library, *then* against GCC's libgcc.

Essentially, this 'hijacks' whatever is AEABI from libgcc while not interfering with what is not AEABI (i.e. what is purely GCC/libgcc internals).

... but we don't need to link vs libgcc (or the compiler-dependent helper library), ever.

We can provide all of the functions we need
normally.

What we need to do, and Marek's patch is fixing about half of the problem, is always provide the required functionality so that we can link ourself.

Once we have Marek's patch in, only PowerPC is relying on "libgcc" for some number of functions, and once that's done we can just remove "LIBGCC" from the system.

Quoted 3 lines

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

To be clear, what I want is for U-Boot to not rely on having a specific configuration of gcc available.

We do not build today with various (and
correctly configured) toolchains because they are not multi-lib and we do not allow hard float.

The massive number of places that tell people
to "fix" this problem by just removing -msoft-float is very wrong.

And
we aren't going to fix that problem by jumping all over stack overflow, we're going to fix that by making it not be a problem.

Quoted 10 lines

1) GCC keeps its somewhat stable but uncontrolled internal "generated code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc, i.e. whatever ibgcc-related but non-AEABI-related changes occur in a GCC release, we won't break them changes in non-AEABI ;

3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI breakages happen in a given GCC toolchain will not break U-Boot.

Quoted 3 lines

4) This design works with any ARM toolchain -- which is kind of evident since it separates generic ARM EABI support from specific toolchain support.

The problem here is what once we do this we are never using anything from linking against libgcc, so there's no reason to.

Signature · 1 line

Tom

Import unified.h from Linux kernel 4.4.6 , commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains macros used in libgcc functions in Linux kernel on ARM and will be needed for the libgcc sync.

Since unified.h defines the W(instr) macro, we must drop this from the macro from memcpy.S , otherwise this triggers a warning about symbol redefinition. In order to keep the changes to unified.h to the minimum, tweak arch/arm/lib/Makefile such that it defines new CONFIG_THUMB2_KERNEL macro, which is already checked by unified.h, only if Thumb build is enabled, but the target does not support Thumb2 . This way we can remove ad-hoc -DMEMSET_NO_THUMB_BUILD and -DMEMCPY_NO_THUMB_BUILD and we do not change the logic.

Signed-off-by Marek Vasut <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Simon Glass <[email protected]>

Cc Tom Rini <[email protected]>

---
 arch/arm/include/asm/assembler.h |   1 +
 arch/arm/include/asm/unified.h   | 140 +++++++++++++++++++++++++++++++++++++++
 arch/arm/lib/Makefile            |   6 +-
 arch/arm/lib/memcpy.S            |   6 --
 4 files changed, 144 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/include/asm/unified.h

arch/arm/include/asm/assembler.h +1 -0

index 11b80fb..ae1e42f 100644
@@ -15,6 +15,7 @@
  */
 
 #include <config.h>
+#include <asm/unified.h>
 
 /*
  * Endian independent macros for shifting bytes within registers.

arch/arm/include/asm/unified.h new file +140 -0

new file mode 100644
index 0000000..a91ae49
@@ -0,0 +1,140 @@
+/*
+ * include/asm-arm/unified.h - Unified Assembler Syntax helper macros
+ *
+ * Copyright (C) 2008 ARM Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_UNIFIED_H
+#define __ASM_UNIFIED_H
+
+#if defined(__ASSEMBLY__) && defined(CONFIG_ARM_ASM_UNIFIED)
+       .syntax unified
+#endif
+
+#ifdef CONFIG_CPU_V7M
+#define AR_CLASS(x...)
+#define M_CLASS(x...)  x
+#else
+#define AR_CLASS(x...) x
+#define M_CLASS(x...)
+#endif
+
+#ifdef CONFIG_THUMB2_KERNEL
+
+#if __GNUC__ < 4
+#error Thumb-2 kernel requires gcc >= 4
+#endif
+
+/* The CPSR bit describing the instruction set (Thumb) */
+#define PSR_ISETSTATE  PSR_T_BIT
+
+#define ARM(x...)
+#define THUMB(x...)    x
+#ifdef __ASSEMBLY__
+#define W(instr)       instr.w
+#else
+#define WASM(instr)    #instr ".w"
+#endif
+
+#else  /* !CONFIG_THUMB2_KERNEL */
+
+/* The CPSR bit describing the instruction set (ARM) */
+#define PSR_ISETSTATE  0
+
+#define ARM(x...)      x
+#define THUMB(x...)
+#ifdef __ASSEMBLY__
+#define W(instr)       instr
+#else
+#define WASM(instr)    #instr
+#endif
+
+#endif /* CONFIG_THUMB2_KERNEL */
+
+#ifndef CONFIG_ARM_ASM_UNIFIED
+
+/*
+ * If the unified assembly syntax isn't used (in ARM mode), these
+ * macros expand to an empty string
+ */
+#ifdef __ASSEMBLY__
+       .macro  it, cond
+       .endm
+       .macro  itt, cond
+       .endm
+       .macro  ite, cond
+       .endm
+       .macro  ittt, cond
+       .endm
+       .macro  itte, cond
+       .endm
+       .macro  itet, cond
+       .endm
+       .macro  itee, cond
+       .endm
+       .macro  itttt, cond
+       .endm
+       .macro  ittte, cond
+       .endm
+       .macro  ittet, cond
+       .endm
+       .macro  ittee, cond
+       .endm
+       .macro  itett, cond
+       .endm
+       .macro  itete, cond
+       .endm
+       .macro  iteet, cond
+       .endm
+       .macro  iteee, cond
+       .endm
+#else  /* !__ASSEMBLY__ */
+__asm__(
+"      .macro  it, cond\n"
+"      .endm\n"
+"      .macro  itt, cond\n"
+"      .endm\n"
+"      .macro  ite, cond\n"
+"      .endm\n"
+"      .macro  ittt, cond\n"
+"      .endm\n"
+"      .macro  itte, cond\n"
+"      .endm\n"
+"      .macro  itet, cond\n"
+"      .endm\n"
+"      .macro  itee, cond\n"
+"      .endm\n"
+"      .macro  itttt, cond\n"
+"      .endm\n"
+"      .macro  ittte, cond\n"
+"      .endm\n"
+"      .macro  ittet, cond\n"
+"      .endm\n"
+"      .macro  ittee, cond\n"
+"      .endm\n"
+"      .macro  itett, cond\n"
+"      .endm\n"
+"      .macro  itete, cond\n"
+"      .endm\n"
+"      .macro  iteet, cond\n"
+"      .endm\n"
+"      .macro  iteee, cond\n"
+"      .endm\n");
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_ARM_ASM_UNIFIED */
+
+#endif /* !__ASM_UNIFIED_H */

arch/arm/lib/Makefile +3 -3

index 7a0fb58..a930744 100644
@@ -80,8 +80,8 @@ CFLAGS_cache-cp15.o := -marm
 
 AFLAGS_REMOVE_memset.o := -mthumb -mthumb-interwork
 AFLAGS_REMOVE_memcpy.o := -mthumb -mthumb-interwork
-AFLAGS_memset.o := -DMEMSET_NO_THUMB_BUILD
-AFLAGS_memcpy.o := -DMEMCPY_NO_THUMB_BUILD
-
+else
+AFLAGS_memset.o := -DCONFIG_THUMB2_KERNEL
+AFLAGS_memcpy.o := -DCONFIG_THUMB2_KERNEL
 endif
 endif

arch/arm/lib/memcpy.S +0 -7

index 7d9fc0f..00602e9 100644
@@ -13,12 +13,6 @@
 #include <linux/linkage.h>
 #include <asm/assembler.h>
 
-#if defined(CONFIG_SYS_THUMB_BUILD) && !defined(MEMCPY_NO_THUMB_BUILD)
-#define W(instr)       instr.w
-#else
-#define W(instr)       instr
-#endif
-
 #define LDR1W_SHIFT    0
 #define STR1W_SHIFT    0
 
--