[PATCH v2 0/4] More x86_64-gnu glibc work

[Sergey Bugaev <bugaevc@gmail.com>]

Changes compared to v1:
* Drop patches that have been pushed
* Address the review comments (hopefully...)
* Some more effort towards splitting changes into commits properly, and not
  like last time
* Rewrite/simplify the heck of init-first.c

I *think* I understood enough about how init-first.c worked to change it with
some confidence, rather than just trying to replicate what the i386 version was
doing, but for x86_64. I was able to get the much simplified i386 version to
work -- there no longer are any return address rewriting tricks, and only a
single weird jump out of a call stack in the !SHARED config. init & init1 are
unified into one function / code path, as are doinit and doinit1. call_init is
gone. There are no longer any varargs, nor assumptions that function args are
passed on the stack -- everything is dealt with through a pointer. Overall, I
think this version is much cleaner.

I've tried to write some comments about how _hurd_stack_setup () works. There's
really not much code to it, but it is tricky, so better have it documented.

In my testing, both SHARED and !SHARED versions still work (on i386). Early
boot !SHARED seems to work too -- specifically, I replaced the stock
/hurd/ext2fs.static with the one I cross-built with this version of glibc in
the boot script, and it seemed to find its arguments just fine (though the
system did not actually fully boot up, but that was likely for some unrealted
reason...).

So please don't trust my (brief and unreliable) testing, and do your own.

As for x86_64, yes, I have verified that on x86_64-pc-linux-gnu argc/argv/env
arrive on-stack just like the code in _hurd_stack_setup () expects them to.

I still don't understand why __LIBC_NO_TLS () is supposed to return 0 when we
have the early TLS configured, but this seems to be what the i386 version does.

Note: this (TLS) still depends on the gnumach patch adding
i386_fsgs_base_state. If the API is alright, can we push it without an
implementation, so that userland code (glibc) can be built against it?

Note: the other still unpushed patches I'm carrying locally are
"htl: Make pthread_mutex_t pointer-aligned" and the mach-machine part of
"mach: Look for mach_i386.defs on x86_64 too". You may need to apply them to
actually build any of this on x86_64.

Sergey Bugaev (4):
  hurd: Simplify init-first.c further
  hurd: Generalize init-first.c to support x86_64
  hurd: Implement TLS for x86_64
  htl: Add pthreadtypes-arch.h for x86_64

 sysdeps/mach/hurd/dl-sysdep.c                |   5 +-
 sysdeps/mach/hurd/i386/dl-machine.h          |   7 -
 sysdeps/mach/hurd/{i386 => x86}/init-first.c | 220 ++++++++-----------
 sysdeps/mach/hurd/x86_64/tls.h               | 215 ++++++++++++++++++
 sysdeps/x86_64/htl/bits/pthreadtypes-arch.h  |  36 +++
 5 files changed, 345 insertions(+), 138 deletions(-)
 delete mode 100644 sysdeps/mach/hurd/i386/dl-machine.h
 rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (67%)
 create mode 100644 sysdeps/mach/hurd/x86_64/tls.h
 create mode 100644 sysdeps/x86_64/htl/bits/pthreadtypes-arch.h

-- 
2.39.2