* the definition of (u)int64_t with gcc -m32 in stdint.h
@ 2014-08-21 15:15 Natanael Copa
2014-08-21 15:25 ` Khem Raj
0 siblings, 1 reply; 3+ messages in thread
From: Natanael Copa @ 2014-08-21 15:15 UTC (permalink / raw)
To: musl
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.
-nc
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: the definition of (u)int64_t with gcc -m32 in stdint.h
2014-08-21 15:15 the definition of (u)int64_t with gcc -m32 in stdint.h Natanael Copa
@ 2014-08-21 15:25 ` Khem Raj
2014-08-21 16:47 ` Rich Felker
0 siblings, 1 reply; 3+ messages in thread
From: Khem Raj @ 2014-08-21 15:25 UTC (permalink / raw)
To: musl
On Thu, Aug 21, 2014 at 8:15 AM, Natanael Copa <ncopa@alpinelinux.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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: the definition of (u)int64_t with gcc -m32 in stdint.h
2014-08-21 15:25 ` Khem Raj
@ 2014-08-21 16:47 ` Rich Felker
0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2014-08-21 16:47 UTC (permalink / raw)
To: Khem Raj; +Cc: musl
On Thu, Aug 21, 2014 at 08:25:40AM -0700, Khem Raj wrote:
> > 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 ?
With separate include dirs for each, yes. But not using the same
includes. glibc treats i386 and x86_64 (and x32) basically as a common
arch, at least as far as headers are concerned, with a lot of the
header content being determined at compile time via __WORDSIZE or
similar. musl treats them all as separate.
Presumably gcc can be configured, at least via the spec file if
nothing else, to use a different include dir when -m32 is passed.
Rich
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-08-21 16:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-21 15:15 the definition of (u)int64_t with gcc -m32 in stdint.h Natanael Copa
2014-08-21 15:25 ` Khem Raj
2014-08-21 16:47 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).