[LTP] [PATCH v8 1/4] Refactor regen.sh script to generate syscalls

[Petr Vorel]

Hi all,

> Hi!
> > +while IFS= read -r arch; do
> > +	(
> > +		echo
> > +		case ${arch} in
> > +		sparc64) echo "#if defined(__sparc__) && defined(__arch64__)" ;;
> > +		sparc) echo "#if defined(__sparc__) && !defined(__arch64__)" ;;
> > +		s390) echo "#if defined(__s390__) && !defined(__s390x__)" ;;
> > +		mips64n32) echo "#if defined(__mips__) && defined(_ABIN32)" ;;
> > +		mips64) echo "#if defined(__mips__) && defined(_ABI64)" ;;
> > +		mipso32) echo "#if defined(__mips__) && defined(_ABIO32) && _MIPS_SZLONG == 32" ;;

The original code was:

-		mips_n32) echo "#if defined(__mips__) && defined(_ABIN32)" ;;
-		mips_n64) echo "#if defined(__mips__) && defined(_ABI64)" ;;
-		mips_o32) echo "#if defined(__mips__) && defined(_ABIO32) && _MIPS_SZLONG == 32" ;;

ifdefs are the same, the only thing which changed are arch names. And these are
also changed, see below. The only problem I see is that the change in
supported-arch.txt below happens in the following commit. Shouldn't the rename
happen in this commit already? syscalls.h file generated from the first commit
is indeed different from the one generated in 2nd and 3rd (which are the same.

+++ b/include/lapi/syscalls/supported-arch.txt
@@ -1,13 +1,13 @@
-aarch64
 arc
+arm64
 arm
-hppa
 i386
 ia64
-loongarch
-mips_n32
-mips_n64
-mips_o32
+loongarch64
+mips64n32
+mips64
+mipso32
+parisc
 powerpc64
 powerpc
 s390x

1st commit have (which is IMHO wrong)
#ifdef __mips_n32__

2nd and 3rd have:
#if defined(__mips__) && defined(_ABIN32)

The reason due postponed changes is, that some arch use

*) echo "#ifdef __${arch}__" ;;

Whoever will do bisecting, cannot use this commit on mips and other affected
archs due broken syscalls.h. This problem appeared in v5. Previously (v3 and v4)
old names were used in generate_syscalls.sh, and in second commit (when the
generate_arch.sh archs was added) were new ones used.

IMHO clearest solution would be to move rename to 1st commit.

> It would be nice to get a confirmation from someone who knows mips that
> these changes in ifdefs are okay, otherwise:

I guess we know the answer thus we don't have to bother mips folks.
But very good catch.

Kind regards,
Petr