Re: [PATCH 05/20] lib/cobalt: Introduce wrappers_time64.c

On Fri, 2026-02-20 at 15:36 +0100, Jan Kiszka wrote:
> On 20.02.26 10:08, Florian Bezdeka wrote:
> > All COBALT_IMPL_TIME64() services will be moved afterwards - step by
> > step - into the newly introduced wrappers_time64.c. At the end that
> > should allow us to compile libcobalt with time64_t support leaving
> > the native time_t services in place.
> > 
> > Currently, all native time_t services are replaced by the 64 bit
> > variants. That is OK as long as applications are rebuild after
> > libcobalt, but we try to remove this limitation now.
> > 
> > Signed-off-by: Florian Bezdeka <[email protected]>
> > ---
> >  lib/cobalt/Makefile.am       | 3 ++-
> >  lib/cobalt/wrappers_time64.c | 6 ++++++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/cobalt/Makefile.am b/lib/cobalt/Makefile.am
> > index f461e570ed42a0d5cbc43eabb373c3c9edd83bad..17e203f9015fe2bb5306609e4d51c62f3a725780 100644
> > --- a/lib/cobalt/Makefile.am
> > +++ b/lib/cobalt/Makefile.am
> > @@ -43,7 +43,8 @@ libcobalt_la_SOURCES =		\
> >  	timerfd.c		\
> >  	trace.c			\
> >  	umm.c			\
> > -	wrappers.c
> > +	wrappers.c		\
> > +	wrappers_time64.c
> 
> 
> So, a should we do a wrapper_off64 for mmap, or put both into the same
> one? I don't have a good name for common one yet, though.
> 

Assuming we want to follow the same pattern as we do for the time64
series - both worlds provided within one libcobalt build:

At the end libcobalt has to provide two wrappers / symbols. One for
native and one for off64.

Linker magic (needed for __STD() and __RT() anyway) should do the
necessary routing.

As mmap() already resides in its own compile unit (which is fine, it's
not related to time64_t) we might follow the same implementation
pattern: Compile mmap.c twice, with different flags. Something similar
to the COBALT_IMPL_TIME64() macro would be needed - based on different
glibc / compile flag checks.