Re: [DTrace-devel] [PATCH 2/4] test: Use syscall in case of no execveat() wrapper

[Eugene Loh <eugene.loh@oracle.com>]

On 10/7/25 11:38, Kris Van Hees wrote:

> On Mon, Oct 06, 2025 at 05:57:24PM -0400, eugene.loh--- via DTrace-devel wrote:
>> From: Eugene Loh <eugene.loh@oracle.com>
>>
>> While execveat() appeared in kernel 3.19, GNU C library support
>> came later.  We are still testing on some systems with older libc.
> Wow, we do?

Yeah, I know.

> I am curious where...

E.g., I just launched a fresh OCI OL8 instance.

$ uname -r
5.15.0-312.187.5.1.el8uek.x86_64
$ ls -l /usr/lib64/libc.so*
-rw-r--r--. 1 root root 253 Aug  5 17:05 /usr/lib64/libc.so
lrwxrwxrwx. 1 root root  12 Aug  5 17:06 /usr/lib64/libc.so.6 -> 
libc-2.28.so
$ nm /usr/lib64/libc.so.6 |& grep execve
00000000000388d0 t __execve
00000000000388d0 W execve
0000000000108500 T fexecve
00000000000388d0 t __GI___execve
00000000000388d0 t __GI_execve

On an OL9 instance I get:

$ ls -l /usr/lib64/libc.*
-rw-r--r--. 1 root root 7000662 Aug  5 08:18 /usr/lib64/libc.a
-rw-r--r--. 1 root root     253 Aug  5 08:15 /usr/lib64/libc.so
-rwxr-xr-x. 1 root root 2544448 Aug  5 08:18 /usr/lib64/libc.so.6
$ nm /usr/lib64/libc.so.6 | grep execve
00000000000d9eb0 t __execve
00000000000d9eb0 W execve
00000000000fd300 T execveat
00000000000d9ee0 T fexecve
00000000000d9eb0 t __GI___execve
00000000000d9eb0 t __GI_execve
$ ldd --version
ldd (GNU libc) 2.34

>> Do not assume libc has an execveat() wrapper:  use syscall().
>>
>> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>

Thanks.