Hi Xuerui.
Thanks for you comments.
On 2022/6/9 下午6:04, WANG Xuerui wrote:
On 2022/6/9 10:42, Song Gao wrote:
We should disable '__BITS_PER_LONG' at [1] before run gensyscalls.sh
[1] arch/loongarch/include/uapi/asm/bitsperlong.h
I'm not sure why this is necessary, is this for building on 32-bit
where __BITS_PER_LONG are (incorrectly) reflecting the host bitness?
See gensyscalls.sh read_includes()
__BITS_PRE_LONG had been defined in '-D__BITS_PER_LONG=${bits}' .
If this is the case, arch/riscv uses the same trick (they are defining
__BITS_PER_LONG as (__SIZEOF_POINTER__ * 8), which is essentially the
same), so they should fail without the hack described here as well. I
don't know if something else could be tweaked to get rid of this hack
(currently unable to investigate deeper for you, taking a break
reviewing this in the middle of my day job).
See gensyscall.sh read_includes()
-D_UAPI_ASM_$(upper ${arch})_BITSPERLONG_H \
and kernel arch/riscv/include/uapi/asm/bitsperlong.h
#ifndef _UAPI_ASM_RISCV_BITSPERLONG_H
#define _UAPI_ASM_RISCV_BITSPERLONG_H
So riscv couldn't get " warning: "__BITS_PER_LONG" redefined"
For fix it ,
@@ -44,6 +46,7 @@ read_includes()
cpp -P -nostdinc -fdirectives-only \
-D_UAPI_ASM_$(upper ${arch})_BITSPERLONG_H \
+ -D__ASM_$(upper ${arch})_BITSPERLONG_H \
-D__BITS_PER_LONG=${bits} \
-I${linux}/arch/${arch}/include/uapi/ \
-I${linux}/include/uapi \
How about this?
Thanks.
Song Gao
