[RFC PATCH u-boot 02/12] sandbox: errno: avoid conflict with libc's errno

[Marek Behun <marek.behun@nic.cz>]

On Fri, 5 Mar 2021 18:21:51 +0100
Heinrich Schuchardt <xypron.glpk@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@gmail.com> wrote:
> >  
> >> On Wed, Mar 3, 2021 at 12:13 PM Marek Beh?n <marek.behun@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.

Marek