mbox series

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

Message ID 20230212111044.610942-1-bugaevc@gmail.com
Headers show
Series Towards glibc on x86_64-gnu | expand

Message

Sergey Bugaev Feb. 12, 2023, 11:10 a.m. UTC 
Hello!

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;
- INTR_MSG_TRAP.

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.

Sergey

Comments

Samuel Thibault Feb. 12, 2023, 4:12 p.m. UTC | #1 
Hello,

Sergey Bugaev via Libc-alpha, le dim. 12 févr. 2023 14:10:31 +0300, a ecrit:
> The main missing pieces seem to be, ordered by scariness increasing:
> - missing x86_64 thread state definition in the kernel headers;
> - TLS things;
> - INTR_MSG_TRAP.

INTR_MSG_TRAP shouldn't be hard. It's the trampoline part which will
be.  Also, sysdeps/mach/hurd/i386/init-first.c. But possibly that part
could be simplified on 32bit first, now that libpthread just takes the
existing stack rather that forcing to use one, see 9cec82de715b which
started to simplify things.

Samuel