libsysdecode: Using ${SRCTOP}/sys to generate tables.h

[dchagin]

Summary

To generate tables.h use headers under $DESTDIR but libsysdecode builds
using headers under $SRCTOP dir. Changing header file under $SRCTOP can
leads to break libsysdecode build, e.g., removimg defines which is used
in tables.h.
Also we does not install compat/linux headers to the $DESTDIR that
prevents to decode Linuxulator's syscalls.

[dchagin]

finished, tested on arm64 (sysarch), amd64

[dchagin]

Summary changed:

To generate tables.h headers under $DESTDIR are used but libsysdecode uses mixed headers to build.
The difference between the same header located in the $DESTDIR and in the $SRC can cause the libsysdecode to fail to build.
Also we does not install compat/linux headers, that prevents us to decode Linuxulator's syscalls.

[dchagin]

Add -I${SRCTOP}/lib/libsysdecode to CFLAGS

[jhb]

Hmm, it might be good to link the related commits together to understand the motivation. libsysdecode is userspace, so it really shouldn't be using <sys/aio.h>, etc.

I think what you are trying to do is to add support for new tables that are in non-installed headers? For that I think we might want to try a slightly different approach, e.g. maybe have a second mktables variant that runs against a different tree, or add a new gen_sys_table function that runs against headers in the provided SRCTOP/sys (as an additional argument passed to mktables).

[dchagin]

In D35209#798691, @jhb wrote:

Hmm, it might be good to link the related commits together to understand the motivation. libsysdecode is userspace, so it really shouldn't be using <sys/aio.h>, etc.

I think what you are trying to do is to add support for new tables that are in non-installed headers? For that I think we might want to try a slightly different approach, e.g. maybe have a second mktables variant that runs against a different tree, or add a new gen_sys_table function that runs against headers in the provided SRCTOP/sys (as an additional argument passed to mktables).

I'm trying to fix two problems.
The first one you have already written about. I want to generate tables for headers from compat/linux.
Second, correct of the inconsistency of libsysdecode build process. Where mktables uses intsalled includes, while libsysdecode builds (flags.c for example) using source headers.
so, if some of source sys/*.h has changed, e.g., deleted WLINUXCLONE define from sys/wait.h., build fails.

[jhb]

In D35209#798700, @dchagin wrote:

In D35209#798691, @jhb wrote:

Hmm, it might be good to link the related commits together to understand the motivation. libsysdecode is userspace, so it really shouldn't be using <sys/aio.h>, etc.

I think what you are trying to do is to add support for new tables that are in non-installed headers? For that I think we might want to try a slightly different approach, e.g. maybe have a second mktables variant that runs against a different tree, or add a new gen_sys_table function that runs against headers in the provided SRCTOP/sys (as an additional argument passed to mktables).

I'm trying to fix two problems.
The first one you have already written about. I want to generate tables for headers from compat/linux.
Second, correct of the inconsistency of libsysdecode build process. Where mktables uses intsalled includes, while libsysdecode builds (flags.c for example) using source headers.
so, if some of source sys/*.h has changed, e.g., deleted WLINUXCLONE define from sys/wait.h., build fails.

During buildworld we build against the /usr/include in the sysroot though. If you are building standalone outside of buildworld, then trying to parse the system /usr/include is more correct.

[dchagin]

In D35209#799430, @jhb wrote:

In D35209#798700, @dchagin wrote:

In D35209#798691, @jhb wrote:

Hmm, it might be good to link the related commits together to understand the motivation. libsysdecode is userspace, so it really shouldn't be using <sys/aio.h>, etc.

I think what you are trying to do is to add support for new tables that are in non-installed headers? For that I think we might want to try a slightly different approach, e.g. maybe have a second mktables variant that runs against a different tree, or add a new gen_sys_table function that runs against headers in the provided SRCTOP/sys (as an additional argument passed to mktables).

I'm trying to fix two problems.
The first one you have already written about. I want to generate tables for headers from compat/linux.
Second, correct of the inconsistency of libsysdecode build process. Where mktables uses intsalled includes, while libsysdecode builds (flags.c for example) using source headers.
so, if some of source sys/*.h has changed, e.g., deleted WLINUXCLONE define from sys/wait.h., build fails.

During buildworld we build against the /usr/include in the sysroot though. If you are building standalone outside of buildworld, then trying to parse the system /usr/include is more correct.

Ah, ok, thak you) Is it ok for you if I create separate mktables especially for compat/linux includes?

[dchagin]

fully reworked, replaced by: https://reviews.freebsd.org/D35353 and https://reviews.freebsd.org/D35354