On 3/25/16 6:35 AM, Waldemar Brodkorb wrote:
Hi Anthony,
Anthony G. Basile wrote,
From: "Anthony G. Basile"
<blueness(a)gentoo.org>
On systems where uClibc doesn't provide an arch specific byteswap.h,
we fall back on bits/byteswap-common.h. However, there is a bug
in this header in the __bswap_constant_64(x) macro. If, for example,
a double is passed, we get "invalid operands to binary &" in which we
mismatch a 'double' and 'long long unsigned int'. The newer glibc
headers fix this and so we import them.
I have an issue with the patch on ARM Cortex-M4 (no MMU).
Any idea? Compile works fine without your patch.
/home/wbx/embedded-test/openadk/toolchain_generic-arm_uclibc-ng_cortex_m4_soft_eabi/usr/bin/arm-openadk-uclinux-uclibceabi-gcc
-c libc/string/arm/memcpy.S -o libc/string/arm/memcpy.o -
Wall -Wstrict-prototypes -Wstrict-aliasing -funsigned-char
-fno-builtin -fno-asm -fmerge-all-constants -msoft-float
-mlittle-endian -mthumb -fno-stack-protector -nostdinc -I./include -
I./include -include libc-symbols.h -I./libc/sysdeps/linux/arm
-I./libc/sysdeps/linux -I./ldso/ldso/arm -I./ldso/include -I.
-DSTATIC -Os -fstrict-aliasing -fwrapv -fno-ident -fhonour-c
opts -mcpu=cortex-m4 -mfloat-abi=soft -Wl,-elf2flt -Os -pipe
-fomit-frame-pointer -fno-unwind-tables
-fno-asynchronous-unwind-tables -mthumb -Wa,-mimplicit-it=thumb
-mno-thumb-interwork -Wa,-mfloat-abi=soft -I./libc/sysdeps/linux/common -isystem
/home/wbx/embedded-test/openadk/toolchain_generic-arm_uclibc-ng_cortex_m4_soft_eabi/usr/lib/gcc/arm-openadk-uclinux-uclibc
eabi/5.3.0/include-fixed -isystem
/home/wbx/embedded-test/openadk/toolchain_generic-arm_uclibc-ng_cortex_m4_soft_eabi/usr/lib/gcc/arm-openadk-uclinux-uclibceabi/5.3.0/include
-I/home/w
bx/embedded-test/openadk/target_generic-arm_uclibc-ng_cortex_m4_soft_eabi/usr/include/
-DNDEBUG -DIN_LIB=libc -MT libc/string/arm/memcpy.o -MD -MP -MF
libc/string/arm/.memcpy.o.dep -D_
_ASSEMBLER__ -Wa,--noexecstack
./include/bits/kernel_types.h: Assembler messages:
./include/bits/kernel_types.h:10: Error: bad instruction `typedef
unsigned short __kernel_dev_t'
./include/bits/kernel_types.h:11: Error: bad instruction `typedef
unsigned long __kernel_ino_t'
./include/bits/kernel_types.h:12: Error: bad instruction `typedef
unsigned short __kernel_mode_t'
./include/bits/kernel_types.h:13: Error: bad instruction `typedef
unsigned short __kernel_nlink_t'
./include/bits/kernel_types.h:14: Error: bad instruction `typedef
long __kernel_off_t'
./include/bits/kernel_types.h:15: Error: bad instruction `typedef
int __kernel_pid_t'
./include/bits/kernel_types.h:16: Error: bad instruction `typedef
unsigned short __kernel_ipc_pid_t'
./include/bits/kernel_types.h:17: Error: bad instruction `typedef
unsigned short __kernel_uid_t'
./include/bits/kernel_types.h:18: Error: bad instruction `typedef
unsigned short __kernel_gid_t'
./include/bits/kernel_types.h:19: Error: bad instruction `typedef
unsigned int __kernel_size_t'
Thanks for catching this. I get what's going on but I'm not sure of an
easy fix. byteswap.h from glibc introduces #include <bits/types.h>
which in turn includes <bits/kernel_types.h> (ifdef _LIBC), both of
which have typedefs. This is not a problem when these headers get
included in .c files but they are a problem when they are included in .S
files. This happens in this case through #include <endian.h> which is
in libc/string/arm/_memcpy.S and and strlen.S. You have a similar case
with arch=sh.
If you're wondering what glibc does, its header stacking is different
avoiding the issue altogether.
For now I have to withdraw this patch until I figure out a way around
it. While it is the correct way to address the original issue, it
introduces a regression. So now I'm thinking of how maybe to edit the
.S files.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197