Page MenuHomeFreeBSD

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

Authored by dchagin on May 14 2022, 4:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 6 2024, 11:52 PM
Unknown Object (File)
Dec 20 2023, 8:08 AM
Unknown Object (File)
Nov 22 2023, 2:11 AM
Unknown Object (File)
Nov 17 2023, 8:33 AM
Unknown Object (File)
Nov 8 2023, 4:25 AM
Unknown Object (File)
Nov 8 2023, 3:41 AM
Unknown Object (File)
Nov 3 2023, 7:22 PM
Unknown Object (File)
Oct 16 2023, 7:24 AM
Subscribers

Details

Reviewers
jhb
emaste
markj
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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45582
Build 42470: arc lint + arc unit

Event Timeline

finished, tested on arm64 (sysarch), amd64

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.

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

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).

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.

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.

In D35209#799430, @jhb 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?