[PATCH] Add build time guard to detect off_t mismatch

[PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

When Xenomai is built without _FILE_OFFSET_BITS=64 on a 32 bit system,
which is the default, but the Xenomai application itself is built later
with _FILE_OFFSET_BITS=64, we get a nasty ABI mismatch. Since only very
few cobalt syscalls use off_t, the mismatch goes undiscovered for a
surprisingly long time. In my case it surfaced only after a realtime
application which uses mmap() failed sometimes at mmap() depending on
what functions it called before mmap(). In the good cases it used to
work by chance since the extra bytes used for off_t on the stack were
zero.

To save the next person in the same situation a lot of time, compute
the size of off_t at configure time and compare it against the
application's sizeof(off_t) via a static assertion in a new generated
header, which is included when building Xenomai applications.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 .gitignore                     |  1 +
 configure.ac                   |  4 ++++
 include/Makefile.am            |  2 +-
 include/boilerplate/libc.h     |  1 +
 include/xeno_off_t_assert.h.in | 10 ++++++++++
 5 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 include/xeno_off_t_assert.h.in

diff --git a/.gitignore b/.gitignore
index 402604c59..8b35071c9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,6 +26,7 @@
 /configure
 /include/stamp-h?
 /libtool
+/include/xeno_off_t_assert.h
 /include/xeno_config.h
 /include/xeno_config.h.in*
 /.ccache
diff --git a/configure.ac b/configure.ac
index 0d6dd87b6..b3d08d6f0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -19,6 +19,10 @@ if test x$prefix = xNONE; then
    prefix=$ac_default_prefix
 fi
 
+AC_CHECK_SIZEOF([off_t])
+AC_SUBST([SIZEOF_OFF_T], [$ac_cv_sizeof_off_t])
+AC_CONFIG_FILES([include/xeno_off_t_assert.h])
+
 version_code=`cat $srcdir/config/version-code`
 CONFIG_XENO_VERSION_MAJOR=`expr $version_code : '\([[0-9]]*\)'`
 CONFIG_XENO_VERSION_MINOR=`expr $version_code : '[[0-9]]*\.\([[0-9]]*\)'`
diff --git a/include/Makefile.am b/include/Makefile.am
index 1e9fe0210..05dda9539 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -1,4 +1,4 @@
-nodist_include_HEADERS=$(CONFIG_HEADER)
+nodist_include_HEADERS=$(CONFIG_HEADER) $(top_builddir)/include/xeno_off_t_assert.h
 
 SUBDIRS = 		\
 	boilerplate	\
diff --git a/include/boilerplate/libc.h b/include/boilerplate/libc.h
index 44ddad5af..98d49648a 100644
--- a/include/boilerplate/libc.h
+++ b/include/boilerplate/libc.h
@@ -19,6 +19,7 @@
 #define _BOILERPLATE_LIBC_H
 
 #include <limits.h>
+#include <xeno_off_t_assert.h>
 
 #ifdef __IN_XENO__
 /*
diff --git a/include/xeno_off_t_assert.h.in b/include/xeno_off_t_assert.h.in
new file mode 100644
index 000000000..29b544b29
--- /dev/null
+++ b/include/xeno_off_t_assert.h.in
@@ -0,0 +1,10 @@
+#ifndef XENO_OFF_T_ASSERT_H
+#define XENO_OFF_T_ASSERT_H
+
+#include <sys/types.h>
+
+#define SIZEOF_OFF_T @SIZEOF_OFF_T@
+
+_Static_assert(SIZEOF_OFF_T == sizeof(off_t), "off_t size mismatch");
+
+#endif /* XENO_OFF_T_ASSERT_H */
-- 
2.51.0

Re: [PATCH] Add build time guard to detect off_t mismatch

[Jan Kiszka]

On 07.05.26 14:23, Richard Weinberger wrote:
> When Xenomai is built without _FILE_OFFSET_BITS=64 on a 32 bit system,
> which is the default, but the Xenomai application itself is built later
> with _FILE_OFFSET_BITS=64, we get a nasty ABI mismatch. Since only very
> few cobalt syscalls use off_t, the mismatch goes undiscovered for a
> surprisingly long time. In my case it surfaced only after a realtime
> application which uses mmap() failed sometimes at mmap() depending on
> what functions it called before mmap(). In the good cases it used to
> work by chance since the extra bytes used for off_t on the stack were
> zero.
> 
> To save the next person in the same situation a lot of time, compute
> the size of off_t at configure time and compare it against the
> application's sizeof(off_t) via a static assertion in a new generated
> header, which is included when building Xenomai applications.
> 

This should have been resolved (but apparently we missed most of it) by
0bb6608b6fa7129de1ff4213ddf31298616cbf23. Can you name some of the
remaining mismatches?

Jan

> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  .gitignore                     |  1 +
>  configure.ac                   |  4 ++++
>  include/Makefile.am            |  2 +-
>  include/boilerplate/libc.h     |  1 +
>  include/xeno_off_t_assert.h.in | 10 ++++++++++
>  5 files changed, 17 insertions(+), 1 deletion(-)
>  create mode 100644 include/xeno_off_t_assert.h.in
> 
> diff --git a/.gitignore b/.gitignore
> index 402604c59..8b35071c9 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -26,6 +26,7 @@
>  /configure
>  /include/stamp-h?
>  /libtool
> +/include/xeno_off_t_assert.h
>  /include/xeno_config.h
>  /include/xeno_config.h.in*
>  /.ccache
> diff --git a/configure.ac b/configure.ac
> index 0d6dd87b6..b3d08d6f0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -19,6 +19,10 @@ if test x$prefix = xNONE; then
>     prefix=$ac_default_prefix
>  fi
>  
> +AC_CHECK_SIZEOF([off_t])
> +AC_SUBST([SIZEOF_OFF_T], [$ac_cv_sizeof_off_t])
> +AC_CONFIG_FILES([include/xeno_off_t_assert.h])
> +
>  version_code=`cat $srcdir/config/version-code`
>  CONFIG_XENO_VERSION_MAJOR=`expr $version_code : '\([[0-9]]*\)'`
>  CONFIG_XENO_VERSION_MINOR=`expr $version_code : '[[0-9]]*\.\([[0-9]]*\)'`
> diff --git a/include/Makefile.am b/include/Makefile.am
> index 1e9fe0210..05dda9539 100644
> --- a/include/Makefile.am
> +++ b/include/Makefile.am
> @@ -1,4 +1,4 @@
> -nodist_include_HEADERS=$(CONFIG_HEADER)
> +nodist_include_HEADERS=$(CONFIG_HEADER) $(top_builddir)/include/xeno_off_t_assert.h
>  
>  SUBDIRS = 		\
>  	boilerplate	\
> diff --git a/include/boilerplate/libc.h b/include/boilerplate/libc.h
> index 44ddad5af..98d49648a 100644
> --- a/include/boilerplate/libc.h
> +++ b/include/boilerplate/libc.h
> @@ -19,6 +19,7 @@
>  #define _BOILERPLATE_LIBC_H
>  
>  #include <limits.h>
> +#include <xeno_off_t_assert.h>
>  
>  #ifdef __IN_XENO__
>  /*
> diff --git a/include/xeno_off_t_assert.h.in b/include/xeno_off_t_assert.h.in
> new file mode 100644
> index 000000000..29b544b29
> --- /dev/null
> +++ b/include/xeno_off_t_assert.h.in
> @@ -0,0 +1,10 @@
> +#ifndef XENO_OFF_T_ASSERT_H
> +#define XENO_OFF_T_ASSERT_H
> +
> +#include <sys/types.h>
> +
> +#define SIZEOF_OFF_T @SIZEOF_OFF_T@
> +
> +_Static_assert(SIZEOF_OFF_T == sizeof(off_t), "off_t size mismatch");
> +
> +#endif /* XENO_OFF_T_ASSERT_H */


-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
> An: "richard" <richard@nod.at>, "xenomai" <xenomai@lists.linux.dev>
> Gesendet: Donnerstag, 7. Mai 2026 14:26:37
> Betreff: Re: [PATCH] Add build time guard to detect off_t mismatch

> On 07.05.26 14:23, Richard Weinberger wrote:
>> When Xenomai is built without _FILE_OFFSET_BITS=64 on a 32 bit system,
>> which is the default, but the Xenomai application itself is built later
>> with _FILE_OFFSET_BITS=64, we get a nasty ABI mismatch. Since only very
>> few cobalt syscalls use off_t, the mismatch goes undiscovered for a
>> surprisingly long time. In my case it surfaced only after a realtime
>> application which uses mmap() failed sometimes at mmap() depending on
>> what functions it called before mmap(). In the good cases it used to
>> work by chance since the extra bytes used for off_t on the stack were
>> zero.
>> 
>> To save the next person in the same situation a lot of time, compute
>> the size of off_t at configure time and compare it against the
>> application's sizeof(off_t) via a static assertion in a new generated
>> header, which is included when building Xenomai applications.
>> 
> 
> This should have been resolved (but apparently we missed most of it) by
> 0bb6608b6fa7129de1ff4213ddf31298616cbf23. Can you name some of the
> remaining mismatches?

In my case it was just mmap(). But wouldn't it hurt at any function
or data structure exposed by Xenomai which uses off_t?

So, I suggest applying my change as safeguard mechanism.

Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Jan Kiszka]

On 07.05.26 14:32, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> An: "richard" <richard@nod.at>, "xenomai" <xenomai@lists.linux.dev>
>> Gesendet: Donnerstag, 7. Mai 2026 14:26:37
>> Betreff: Re: [PATCH] Add build time guard to detect off_t mismatch
> 
>> On 07.05.26 14:23, Richard Weinberger wrote:
>>> When Xenomai is built without _FILE_OFFSET_BITS=64 on a 32 bit system,
>>> which is the default, but the Xenomai application itself is built later
>>> with _FILE_OFFSET_BITS=64, we get a nasty ABI mismatch. Since only very
>>> few cobalt syscalls use off_t, the mismatch goes undiscovered for a
>>> surprisingly long time. In my case it surfaced only after a realtime
>>> application which uses mmap() failed sometimes at mmap() depending on
>>> what functions it called before mmap(). In the good cases it used to
>>> work by chance since the extra bytes used for off_t on the stack were
>>> zero.
>>>
>>> To save the next person in the same situation a lot of time, compute
>>> the size of off_t at configure time and compare it against the
>>> application's sizeof(off_t) via a static assertion in a new generated
>>> header, which is included when building Xenomai applications.
>>>
>>
>> This should have been resolved (but apparently we missed most of it) by
>> 0bb6608b6fa7129de1ff4213ddf31298616cbf23. Can you name some of the
>> remaining mismatches?
> 
> In my case it was just mmap(). But wouldn't it hurt at any function
> or data structure exposed by Xenomai which uses off_t?
> 
> So, I suggest applying my change as safeguard mechanism.
> 

mmap is supposed to be fine by now. So we need to understand why it is
not and resolve the issue - or my other patch would be pointless.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> In my case it was just mmap(). But wouldn't it hurt at any function
>> or data structure exposed by Xenomai which uses off_t?
>> 
>> So, I suggest applying my change as safeguard mechanism.
>> 
> 
> mmap is supposed to be fine by now. So we need to understand why it is
> not and resolve the issue - or my other patch would be pointless.

Ah, sorry for not being clear.
Your fix is in next and not part of a release, and the application in
question uses Xenomai 3.2.6...

Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Jan Kiszka]

On 07.05.26 14:55, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>> In my case it was just mmap(). But wouldn't it hurt at any function
>>> or data structure exposed by Xenomai which uses off_t?
>>>
>>> So, I suggest applying my change as safeguard mechanism.
>>>
>>
>> mmap is supposed to be fine by now. So we need to understand why it is
>> not and resolve the issue - or my other patch would be pointless.
> 
> Ah, sorry for not being clear.
> Your fix is in next and not part of a release, and the application in
> question uses Xenomai 3.2.6...

But 3.2.x is not affected by the mmap off_t issue?! Still confused.

Yes, I decided against backport my fix to 3.3.x, so your change could be
an alternative for that branch.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> Ah, sorry for not being clear.
>> Your fix is in next and not part of a release, and the application in
>> question uses Xenomai 3.2.6...
> 
> But 3.2.x is not affected by the mmap off_t issue?! Still confused.

Well, the issue I'm talking about was a build issue.
Xenomai was configured without _FILE_OFFSET_BITS=64, but the application was with.
Not Xenomai's fault, of course.

But when the application started to use mmap() the off_t used in the application
had 8 bytes, but Xenomai expected 4. So, the mmap() offset parameter was wrong.

Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Jan Kiszka]

On 07.05.26 16:10, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>> Ah, sorry for not being clear.
>>> Your fix is in next and not part of a release, and the application in
>>> question uses Xenomai 3.2.6...
>>
>> But 3.2.x is not affected by the mmap off_t issue?! Still confused.
> 
> Well, the issue I'm talking about was a build issue.
> Xenomai was configured without _FILE_OFFSET_BITS=64, but the application was with.
> Not Xenomai's fault, of course.
> 
> But when the application started to use mmap() the off_t used in the application
> had 8 bytes, but Xenomai expected 4. So, the mmap() offset parameter was wrong.

OK, given that Xenomai intercepts the mmap path, we could argue that
this is also stable relevant.

Can you confirm that this issue is truly gone in next, whatever mode you
choose on both sides?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
> Can you confirm that this issue is truly gone in next, whatever mode you
> choose on both sides?

Hmm. Let me build/run a test first.

Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

On Thu, May 7, 2026 at 4:22 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> OK, given that Xenomai intercepts the mmap path, we could argue that
> this is also stable relevant.
>
> Can you confirm that this issue is truly gone in next, whatever mode you
> choose on both sides?

Still had no chance to build or run tests with Xenomai next on my ARM boards.
But I had a look at the code.

I think it's still broken, at least for the following scenario:
- 32 bit application built with  _FILE_OFFSET_BITS=64
- 32 bit libcobalt without
- application calls mmap() using __RT(mmap), so __cobalt_mmap() in libcobalt
- off_t differs in size ass seen by caller and callee

On x86 it works by chance because callee reads only the first 4 bytes
of the 8 byte off_t.
All parameters are on the stack and have 4 byte alignment.

On ARM EABI the story is different.
The first four parameters are in registers r0 to r3, all others on the stack.
5th parameter, fd, is a 4 byte integer, so the caller needs to add 4
bytes padding
to make sure the 6th parameter, off_t, is on an 8 byte alignment
boundary since off_t
is from the callers point of view 8 bytes.
The callee expects off_t being 4 bytes, knows nothing about the
padding and reads
the uninitialized padding bytes as offset.

I don't see how this case is avoided in next.

-- 
Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Jan Kiszka]

On 12.05.26 15:01, Richard Weinberger wrote:
> On Thu, May 7, 2026 at 4:22 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> OK, given that Xenomai intercepts the mmap path, we could argue that
>> this is also stable relevant.
>>
>> Can you confirm that this issue is truly gone in next, whatever mode you
>> choose on both sides?
> 
> Still had no chance to build or run tests with Xenomai next on my ARM boards.
> But I had a look at the code.
> 
> I think it's still broken, at least for the following scenario:
> - 32 bit application built with  _FILE_OFFSET_BITS=64
> - 32 bit libcobalt without
> - application calls mmap() using __RT(mmap), so __cobalt_mmap() in libcobalt
> - off_t differs in size ass seen by caller and callee

A 32-bit app built with _FILE_OFFSET_BITS=64 is supposed to call mmap64
(as symbol). In you scenario above, it should run into an unresolvable
symbol error.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

On Tue, May 12, 2026 at 3:08 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 12.05.26 15:01, Richard Weinberger wrote:
> > On Thu, May 7, 2026 at 4:22 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >> OK, given that Xenomai intercepts the mmap path, we could argue that
> >> this is also stable relevant.
> >>
> >> Can you confirm that this issue is truly gone in next, whatever mode you
> >> choose on both sides?
> >
> > Still had no chance to build or run tests with Xenomai next on my ARM boards.
> > But I had a look at the code.
> >
> > I think it's still broken, at least for the following scenario:
> > - 32 bit application built with  _FILE_OFFSET_BITS=64
> > - 32 bit libcobalt without
> > - application calls mmap() using __RT(mmap), so __cobalt_mmap() in libcobalt
> > - off_t differs in size ass seen by caller and callee
>
> A 32-bit app built with _FILE_OFFSET_BITS=64 is supposed to call mmap64
> (as symbol). In you scenario above, it should run into an unresolvable
> symbol error.

Hmm, not here.
I'm building Xenomai with:  CFLAGS="-m32" ./configure && make -j 8 install
Then a program which does __RT(mmap):
$ gcc -o hog hog.c -m32 -D_FILE_OFFSET_BITS=64
$(/usr/xenomai/bin/xeno-config --cflags --skin=posix --ldflags)
$   nm hog|grep mmap
        U __cobalt_mmap

-- 
Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Florian Bezdeka]

On Tue, 2026-05-12 at 15:15 +0200, Richard Weinberger wrote:
> On Tue, May 12, 2026 at 3:08 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > 
> > On 12.05.26 15:01, Richard Weinberger wrote:
> > > On Thu, May 7, 2026 at 4:22 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > > > OK, given that Xenomai intercepts the mmap path, we could argue that
> > > > this is also stable relevant.
> > > > 
> > > > Can you confirm that this issue is truly gone in next, whatever mode you
> > > > choose on both sides?
> > > 
> > > Still had no chance to build or run tests with Xenomai next on my ARM boards.
> > > But I had a look at the code.
> > > 
> > > I think it's still broken, at least for the following scenario:
> > > - 32 bit application built with  _FILE_OFFSET_BITS=64
> > > - 32 bit libcobalt without
> > > - application calls mmap() using __RT(mmap), so __cobalt_mmap() in libcobalt
> > > - off_t differs in size ass seen by caller and callee
> > 
> > A 32-bit app built with _FILE_OFFSET_BITS=64 is supposed to call mmap64
> > (as symbol). In you scenario above, it should run into an unresolvable
> > symbol error.
> 
> Hmm, not here.
> I'm building Xenomai with:  CFLAGS="-m32" ./configure && make -j 8 install
> Then a program which does __RT(mmap):

__RT() might be the problem here. You will end up in __cobalt_mmap()
unconditionally, right? Does migrating to mmap() with all the wrapping
magic help here?

Probably the same question as we had for the time_t related services: Do
we want one libcobalt build to support both worlds at the same time? 

> $ gcc -o hog hog.c -m32 -D_FILE_OFFSET_BITS=64
> $(/usr/xenomai/bin/xeno-config --cflags --skin=posix --ldflags)
> $   nm hog|grep mmap
>         U __cobalt_mmap
> 
> -- 
> Thanks,
> //richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Richard Weinberger]

On Tue, May 12, 2026 at 4:26 PM Florian Bezdeka
<florian.bezdeka@siemens.com> wrote:
> __RT() might be the problem here. You will end up in __cobalt_mmap()
> unconditionally, right? Does migrating to mmap() with all the wrapping
> magic help here?

When not using __RT(), the unresolved symbol is  __wrap_mmap64().

> Probably the same question as we had for the time_t related services: Do
> we want one libcobalt build to support both worlds at the same time?

At least the application on my desk uses __RT() a lot.
Sorting all this out would make some pople rather unhappy, I guess.

-- 
Thanks,
//richard

Re: [PATCH] Add build time guard to detect off_t mismatch

[Florian Bezdeka]

On Tue, 2026-05-12 at 17:04 +0200, Richard Weinberger wrote:
> On Tue, May 12, 2026 at 4:26 PM Florian Bezdeka
> <florian.bezdeka@siemens.com> wrote:
> > __RT() might be the problem here. You will end up in __cobalt_mmap()
> > unconditionally, right? Does migrating to mmap() with all the wrapping
> > magic help here?
> 
> When not using __RT(), the unresolved symbol is  __wrap_mmap64().

I'm still confused about the missing __wrap symbol, but to repair __RT()
for mmap() we have to do something similar as glibc does:

#ifndef __USE_FILE_OFFSET64
extern void *mmap (void *__addr, size_t __len, int __prot,
		   int __flags, int __fd, __off_t __offset) __THROW;
#else
# ifdef __REDIRECT_NTH
extern void * __REDIRECT_NTH (mmap,
			      (void *__addr, size_t __len, int __prot,
			       int __flags, int __fd, __off64_t
__offset),
			      mmap64);
# else
#  define mmap mmap64
# endif
#endif

The redirect part is most likely missing in Xenomai. Redirect mmap() to
mmap64() in case 64bit offsets are in use.

> 
> > Probably the same question as we had for the time_t related services: Do
> > we want one libcobalt build to support both worlds at the same time?
> 
> At least the application on my desk uses __RT() a lot.
> Sorting all this out would make some pople rather unhappy, I guess.
> 
> -- 
> Thanks,
> //richard