public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Antonios Salios <antonios@mwa.re>
To: libc-help@sourceware.org
Cc: "Jan Henrik Weinstock" <jan@mwa.re>, "Lukas Jünger" <lukas@mwa.re>
Subject: 64 bit time_t on riscv32
Date: Mon, 15 Jan 2024 13:52:52 +0100	[thread overview]
Message-ID: <adb2b94c648ebbacf3b1e934ee2d0dd32688d4f1.camel@mwa.re> (raw)

Hi all!

I'm having trouble with timestamps that are sent by the Linux evdev
interface to userspace applications (such as evtest).
I am using a virtualized riscv32 environment built by Buildroot with
glibc 2.37.

The kernel and userspace do not agree on how to define the timestamps.
The values should be 32-bit, so the kernel uses custom 32-bit __sec &
__usec variables instead of a timeval struct.
Userspace, on the other hand, wants to use a timeval struct, that uses
64-bit time_t on rv32.
The struct in question (input_event) can be found here [1].

According to a kernel maintainer, the __USE_TIME_BITS64 macro should be
set on architectures that use 64-bit time [2], otherwise the kernel
headers will not be able to pick the correct definition. 

When I define __USE_TIME_BITS64 manually, the compiler (gcc 13.2) does
not recognize the __time64_t type: `unknown type name '__time64_t'`.
This is fixed by also defining __LIBC [3], although I'm not sure why
this is necessary.
However, the preprocessor will then pick the correct definition of the
input_event struct.

But now the linker cannot find the reference to __ioctl_time64 (and
__select64) because it is only defined (as an alias) when __TIMESIZE !=
64 [4], which is not the case on rv32.

What am I missing?

Kind regards

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/input.h?h=v6.5.6#n28
[2]
https://lore.kernel.org/lkml/1a528414-f193-4ac0-a911-af426bb48d64@app.fastmail.com/
[3]
https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;hb=glibc-2.37#l220
[4]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ioctl.c;hb=glibc-2.37#l48
-- 
Antonios Salios
Software Engineer

MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734

Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock

             reply	other threads:[~2024-01-15 12:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 12:52 Antonios Salios [this message]
2024-01-15 13:40 ` Florian Weimer
2024-01-15 19:55   ` Adhemerval Zanella Netto
2024-01-15 20:15     ` Adhemerval Zanella Netto
2024-01-15 20:29       ` Arnd Bergmann
2024-01-15 22:26     ` Rich Felker
2024-01-16 11:19       ` Adhemerval Zanella Netto
2024-01-16 15:46         ` Florian Weimer
2024-01-16 15:56           ` Rich Felker
2024-01-16 16:22             ` Florian Weimer
2024-01-16 16:29               ` Adhemerval Zanella Netto
2024-01-16 20:43               ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adb2b94c648ebbacf3b1e934ee2d0dd32688d4f1.camel@mwa.re \
    --to=antonios@mwa.re \
    --cc=jan@mwa.re \
    --cc=libc-help@sourceware.org \
    --cc=lukas@mwa.re \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).