[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC PATCH 0/12] Towards glibc on x86_64-gnu

From: Sergey Bugaev
Subject: [RFC PATCH 0/12] Towards glibc on x86_64-gnu
Date: Sun, 12 Feb 2023 14:10:31 +0300


Seeing that the patches to make binutils and GCC support --target=x86_64-gnu
have recently landed, I thought it would be interesting to try to configure
glibc with --host=x86_64-gnu and see what breaks.

To make things work at least somewhat, I've tried to put some basic directory
& Implies structure in place, then fixed various 64-bit issues in generic code
(these fixes should hopefully be uncontroversial!). Then I have even tried to
actually write some of the missing arch-specific code for x86_64-gnu.

With this patch series, I'm able to 'make install-headers' successfully.
Moreover, I'm able to 'make io/subdir_objs' successfully - which builds a lot
of Hurd-specific, but mostly arch-independent, routines. 'subdir_objs' in
'mach', 'hurd', and 'htl' do not succeed, but a lof of files do get built.

The main missing pieces seem to be, ordered by scariness increasing:
- missing x86_64 thread state definition in the kernel headers;
- TLS things;

Thread state (i.e. a struct with all the register values) should not be that
hard for GNU Mach to define (unless it is defined somewhere already and I'm
just not seeing it).

It seems that GCC expects TLS on x86_64 to be done relative to %fs, not %gs, so
that's what I attempted to do in tls.h. The main thing missing there is the
ability to actually set (and read) the %fs base address of a thread. It is my
understanding (but note that I have no idea what I'm talking about) that on
x86_64 the segment descriptors (as in GDT/LDT) are not used for this, and
instead the address can be set by writing to a MSR. Linux exposes the
arch_prctl (ARCH_[GS]ET_[FG]S) syscall for this; so maybe GNU Mach could also
have an explicit routine for this, perhaps like this:

routine i386_set_fgs_base (
        target_thread: thread_t;
        which: int;
        value: rpc_vm_address_t);

We should not need a getter routine, because one can simply inspect the target
thread's state (unless, again, I misunderstand things horribly).

Anyway; this is an RFC. I don't expect the latter patches to actually get
merged. "I have no idea what I'm doing" applies. Maybe I'm doing things
horribly wrong; tell me!

Note: I'm sending this as a single patch series that consists of patches for
the glibc, MIG, and the Hurd repos. The repo that a patch is for is indicated
in the subject line of each patch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]