[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMKF1srHx6v8Ns-DhS3zMzP7neaFqA0JMhn7QVoP-wMbP-r9xw@mail.gmail.com>
Date: Thu, 21 Aug 2014 08:25:40 -0700
From: Khem Raj <raj.khem@...il.com>
To: musl@...ts.openwall.com
Subject: Re: the definition of (u)int64_t with gcc -m32 in stdint.h
On Thu, Aug 21, 2014 at 8:15 AM, Natanael Copa <ncopa@...inelinux.org> wrote:
> Hi,
>
> After migrating from uclibc to musl libc the Xen hvmloader broke. This
> is a 32bit bootloader that is built on 64 bit hosts with gcc -m32.
>
> Someone told me breakage had to do with datastructs beeing 64 bit even
> with -m32. I also saw someone comment that it shoudl been built with
> -nostdinc.
>
> I tried this and it revealed that yes, indeed, the hvmloader does use
> the host system stdint.h and stdarg.h.
>
> Curious on why it works on uclibc but not with musl i found out that
> uclibc/glibc sets (u)int64_t depening on __WORDSIZE:
>
> # if __WORDSIZE == 64
> typedef long int int64_t;
> # else
> __extension__
> typedef long long int int64_t;
> # endif
>
>
> and wordsize is set in /usr/include/bits/wordsize.h:
> /* Determine the wordsize from the preprocessor defines. */
>
> #if defined __x86_64__
> # define __WORDSIZE 64
> /* This makes /var/run/utmp compatible with 32-bit environment: */
> # define __WORDSIZE_COMPAT32 1
> #else
> # define __WORDSIZE 32
> #endif
>
>
> the __x86_64__ define is set by gcc and is set differently when -m32 is
> specified or not.
>
> A testcase. On uclibc 64 bit host:
> dev-2-7-x86_64:~$ echo '#include <stdint.h>' | gcc -m32 -E - | grep int64
> typedef long long int int64_t;
> typedef unsigned long long int uint64_t;
>
>
> Same on musl libc 64 bit host:
> $ echo '#include <stdint.h>' | gcc -m32 -E - | grep int64
> typedef long int64_t;
> typedef unsigned long uint64_t;
> typedef int64_t int_fast64_t;
> typedef int64_t int_least64_t;
> typedef uint64_t uint_fast64_t;
> typedef uint64_t uint_least64_t;
>
>
> so on musl it is 'long' but on uclibc its 'long long int'.
>
> That explains why it works on uclibc but not on musl.
>
> Now, what is the proper way to fix it? Preferible without replacing
> all (u)int*_t all places in xen code. I doubt upstream will accept that.
>
Do we support multilib with musl yes ?
> -nc
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
