| Message ID | 1464278507-5092-12-git-send-email-marex@denx.de |
|---|---|
| State | Accepted |
| Commit | 91b86e21564de01c0e3deafc72702897993d63ae |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, May 26, 2016 at 06:01:47PM +0200, Marek Vasut wrote: > 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. > > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Albert Aribaud <albert.u.boot@aribaud.net> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Simon Glass <sjg@chromium.org> > Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
On Thu, May 26, 2016 at 06:01:47PM +0200, Marek Vasut wrote: > 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. > > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Albert Aribaud <albert.u.boot@aribaud.net> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Simon Glass <sjg@chromium.org> > Cc: Tom Rini <trini@konsulko.com> > Reviewed-by: Tom Rini <trini@konsulko.com> Applied to u-boot/master, thanks! And since this change was contentious when previously proposed, I'm going to explain why I'm taking this now. There are a number of correctly configured toolchains out there today that fail to build U-Boot on some platforms. This is because we're giving the compiler conflicting requests (build soft-float! use whatever libgcc you have!). The era of multilib toolchains being prevalent (at least for 32bit ARM) is long over. The right thing to have done, always, would be to provide the required functions ourselves so that we are in control. So, thanks again Marek for following up on the series as I had asked you to, this fixes build failures for me on about a dozen platforms.
On 4 June 2016 at 02:00, Tom Rini <trini@konsulko.com> wrote: > On Thu, May 26, 2016 at 06:01:47PM +0200, Marek Vasut wrote: > >> 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. >> >> Signed-off-by: Marek Vasut <marex@denx.de> >> Cc: Albert Aribaud <albert.u.boot@aribaud.net> >> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> >> Cc: Simon Glass <sjg@chromium.org> >> Cc: Tom Rini <trini@konsulko.com> >> Reviewed-by: Tom Rini <trini@konsulko.com> > > Applied to u-boot/master, thanks! > > And since this change was contentious when previously proposed, I'm > going to explain why I'm taking this now. There are a number of > correctly configured toolchains out there today that fail to build > U-Boot on some platforms. This is because we're giving the compiler > conflicting requests (build soft-float! use whatever libgcc you have!). > The era of multilib toolchains being prevalent (at least for 32bit ARM) > is long over. The right thing to have done, always, would be to provide > the required functions ourselves so that we are in control. So, thanks > again Marek for following up on the series as I had asked you to, this > fixes build failures for me on about a dozen platforms. Thank you Marek! - Simon
> 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. I agree with this change but is this even true? my toolchain(linaro) has 28 different versions of libgcc.a Thanks Michael On Mon, Jun 6, 2016 at 7:35 PM, Simon Glass <sjg@chromium.org> wrote: > On 4 June 2016 at 02:00, Tom Rini <trini@konsulko.com> wrote: > > On Thu, May 26, 2016 at 06:01:47PM +0200, Marek Vasut wrote: > > > >> 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. > >> > >> Signed-off-by: Marek Vasut <marex@denx.de> > >> Cc: Albert Aribaud <albert.u.boot@aribaud.net> > >> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > >> Cc: Simon Glass <sjg@chromium.org> > >> Cc: Tom Rini <trini@konsulko.com> > >> Reviewed-by: Tom Rini <trini@konsulko.com> > > > > Applied to u-boot/master, thanks! > > > > And since this change was contentious when previously proposed, I'm > > going to explain why I'm taking this now. There are a number of > > correctly configured toolchains out there today that fail to build > > U-Boot on some platforms. This is because we're giving the compiler > > conflicting requests (build soft-float! use whatever libgcc you have!). > > The era of multilib toolchains being prevalent (at least for 32bit ARM) > > is long over. The right thing to have done, always, would be to provide > > the required functions ourselves so that we are in control. So, thanks > > again Marek for following up on the series as I had asked you to, this > > fixes build failures for me on about a dozen platforms. > > Thank you Marek! > > - Simon > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
diff --git a/lib/Kconfig b/lib/Kconfig index 2b97c2b..02ca405 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -14,6 +14,7 @@ config HAVE_PRIVATE_LIBGCC config USE_PRIVATE_LIBGCC bool "Use private libgcc" depends on HAVE_PRIVATE_LIBGCC + default y if HAVE_PRIVATE_LIBGCC && ((ARM && !ARM64) || MIPS) help This option allows you to use the built-in libgcc implementation of U-Boot instead of the one provided by the compiler.
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. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> --- V2: Enable the private libgcc only for ARM<=7 and MIPS --- lib/Kconfig | 1 + 1 file changed, 1 insertion(+)