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

On Tue, 2026-05-12 at 15:15 +0200, Richard Weinberger wrote:
> On Tue, May 12, 2026 at 3:08 PM Jan Kiszka <[email protected]> wrote:
> > 
> > On 12.05.26 15:01, Richard Weinberger wrote:
> > > On Thu, May 7, 2026 at 4:22 PM Jan Kiszka <[email protected]> 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