syscall detection is broken in meson build

[didib]

Environment

# copypaste this script into your shell and replace it with the output
[root@3d0837c045fa /]# date
Wed Feb 22 07:10:31 UTC 2023
[root@3d0837c045fa /]# r2 -v
radare2 5.8.2 0 @ linux-x86-64 git.5.8.2
commit: unknown build: 2023-01-25__00:00:00
[root@3d0837c045fa /]# uname -ms
Linux x86_64

This is a fedora 37 container (on a RHEL 8 machine, probably irrelevant), using the radare2 build of fedora. At first I thought it's a packaging bug in fedora, thus reported it at https://bugzilla.redhat.com/show_bug.cgi?id=2170036 , but further investigation might imply it's a general bug in the meson build, thus current report.

Description

syscalls detection does not work, apparently because the way the meson build generates the syscall *.sdb files is broken.

Test

Do a meson build - e.g. something like:

meson build1 .
meson compile -C build1

Fedora's spec file is here, for reference:

https://src.fedoraproject.org/rpms/radare2/blob/rawhide/f/radare2.spec

Using such a build, run e.g.:

[root@3d0837c045fa /]# r2 /bin/bash
WARN: run r2 with -e bin.cache=true to fix relocations in disassembly
[0x00032ed0]> asl 77
ERROR: Unknown syscall number
[0x00032ed0]> asl ftruncate
77

The github linux-static build (using make) does work well on the same machine. Checking the logs of both runs:

Fedora:

https://koji.fedoraproject.org/koji/taskinfo?taskID=97322791

[399/1188] /builddir/build/BUILD/radare2-5.8.2/x86_64-redhat-linux-gnu/sdb libr/syscall/d/linux-x86-64.sdb == ../libr/syscall/d/linux-x86-64.sdb.txt

github (a recent master build picked randomly, can't find in github the action for a specific tag):

https://github.com/radareorg/radare2/actions/runs/4127735691/jobs/7131308671

2023-02-08T19:48:06.8914288Z "/bin/sh" gen.sh < linux-x86-64.sdb.txt | ../../..//libr/../shlr/sdb//sdb linux-x86-64.sdb =

The make/github build calls gen.sh on the text file, which "duplicates" it - adds the "opposite" direction, AFAIU - the text file stores "ftruncate=0x80,77,2," and gen.sh adds "0x80.77=ftruncate", for the above example. The meson build does not.

A somewhat shallow further checking of the git log hints that this might have been a regression which was part of 657524a. If so, perhaps parts of this should be reverted.

Thanks!

[trufae]

Good finding! This needs to be implemented for meson indeed. Funny that after 4 years of introducing meson we are still missing things that are handled properly with make! Thanks for reporting! I'll take a look at it

[trufae]

Can you please try the PR and check if its behaving as expected?

[xambroz]

Thanks it works.

[didib]

Sorry, I am not sure it's complete. When passing an arm 64 binary (I suppose syscalls DB choice is automatic):

[0x0002c980]> k syscall/* | grep ftru
0.46=ftruncate
ftruncate=0,46
[0x0002c980]> asl ftruncate
46
[0x0002c980]> asl 46
ERROR: Unknown syscall number
[0x0002c980]> 

Also:

[ybardavi@ybardavi d]$ "/bin/sh" gen.sh < linux-arm-64.sdb.txt > linux-arm-64.sdb.txt.gensh
[ybardavi@ybardavi d]$ python3 gen.py ../../../shlr/sdb/src/sdb linux-arm-64.sdb.txt linux-arm-64.sdb-pygen
[ybardavi@ybardavi d]$ diff -ub linux-arm-64.sdb.txt.gensh linux-arm-64.sdb.txt.tmp | head
--- linux-arm-64.sdb.txt.gensh  2023-02-27 10:46:57.237426429 +0200
+++ linux-arm-64.sdb.txt.tmp    2023-02-27 10:47:00.253476985 +0200
@@ -1,102 +1,102 @@
 _=0x0
 0.0=io_setup
-io_setup=0,0,,
+io_setup=0,0
 0.1=io_destroy
-io_destroy=0,1,,
+io_destroy=0,1

(linux-arm-64.sdb.txt.tmp is generated, and not removed, by gen.py).

Not sure what's the significance of the extra commas.

[didib]

Reopening, for visibility.

[didib]

Well, I can't see how. @trufae Would you like me to open a separate issue? I didn't check all archs - linux_x86_64 seems ok, linux_arm_64 seems still broken. Thanks.

[xambroz]

At least from the SDB point of view it looks ok for arm64:

$ sdb linux-x86-64.sdb |grep ftruncate
0x80.77=ftruncate
ftruncate=0x80,77,2,


$ sdb linux-arm-64.sdb |grep ftruncate
ftruncate=0,46
0.46=ftruncate


The linux-arm-32.sdb looks much smaller and is missing the ftruncate

[/usr/share/radare2/5.8.2/syscall] 2023-03-16 11:33:33 +0100
$ ls -la
total 724
drwxr-xr-x.  2 root root   4096 2023-02-26_16:23:38 .
drwxr-xr-x. 12 root root   4096 2023-02-26_15:42:37 ..
-rw-r--r--.  1 root root  33876 2023-02-26_15:39:52 darwin-arm-32.sdb
-rw-r--r--.  1 root root  33876 2023-02-26_15:39:52 darwin-arm-64.sdb
-rw-r--r--.  1 root root  41670 2023-02-26_15:39:52 darwin-x86-32.sdb
-rw-r--r--.  1 root root  47021 2023-02-26_15:39:52 darwin-x86-64.sdb
-rw-r--r--.  1 root root  10870 2023-02-26_15:39:52 dos-x86-16.sdb
-rw-r--r--.  1 root root   6447 2023-02-26_15:39:52 freebsd-x86-32.sdb
-rw-r--r--.  1 root root  33876 2023-02-26_15:39:52 ios-arm-32.sdb
-rw-r--r--.  1 root root  33876 2023-02-26_15:39:52 ios-arm-64.sdb
-rw-r--r--.  1 root root  27446 2023-02-26_15:39:52 ios-x86-32.sdb
-rw-r--r--.  1 root root   4696 2023-02-26_15:39:52 linux-arm-32.sdb

[xambroz]

@didib @trufae - is this right?

[didib]

I didn't check arm 32, might have the same or a similar issue. Not sure what the output of sdb means and how it should look for radare2 to work well. See my previous comment for what I did check.

Do the extra commas added by gen.sh have any significance? Apparently yes. If so, perhaps the py version should add them as well.

I don't mind pushing a patch to add this myself, but would feel uneasy doing this without a deeper understanding of the formats of these files, what these commas mean, etc., and learning all of this will take more time, to me - I hope @trufae can answer more easily...