[RFC PATCH u-boot 02/12] sandbox: errno: avoid conflict with libc's errno
marek.behun at nic.cz
Sun Mar 7 04:14:44 CET 2021
On Fri, 5 Mar 2021 18:21:51 +0100
Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 05.03.21 16:37, Marek Behun wrote:
> > On Fri, 5 Mar 2021 11:00:45 +0800
> > Bin Meng <bmeng.cn at gmail.com> wrote:
> >> On Wed, Mar 3, 2021 at 12:13 PM Marek Behún <marek.behun at nic.cz> wrote:
> >>> When building with LTO, the system libc's `errno` variable used in
> >>> arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
> >>> lib/errno.c) with the following error:
> >>> .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
> >>> section .tbss mismatches non-TLS reference in
> >>> /tmp/u-boot.EQlEXz.ltrans0.ltrans.o
> >> Do you know if this is the expected behavior when enabling LTO on the compiler?
> > I don't, but this is a bug anyway. The symbol clashes with the symbol
> > from glibc. Does somebody know whether the usage of this symbol in os.c
> > does really use glibc's version or U-Boot's one?
> Hello Marek,
> Why do you resort to assembler in your patch instead of simply using:
> #define errno __uboot_errno
> to substitute the symbol?
Meeeeeh. :D That would just make error messages from gcc more
complicated, if suddenly the compiler spat out 2 more lines, saying "in
expansion of macro...".
I think that using attributes, static inline functions and everything
else the compiler provides instead of macros is better.
> Why explicitly set errno = 0? Globals are automatically initialized to zero.
I just added the symbol renaming part, the = 0 assignment was already
there. I don't think this commit should remove it. If we want that, we
can make it in another commit.
More information about the U-Boot