[PATCH] [round 2] Upstreaming a large amount of patches

Hi again,

so this is round 2; I've now prepared a bunch of other patches for
dietlibc. This is probably the last round with a large number of
patches in a single email, because most other things I'll probably send
as individual patches to the list when they come up.

Here we go (patches are wget-able, against a current CVS checkout). All
patches are also viewable here:
https://gist.github.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec

FEATURES
-----------------------------------------------------------------------

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/features-B01-valgrind.patch

   Patch author: Christian Seiler <[email protected]>

   Add valgrind detection support to remaining string routines, see
   the previous discussion we had on this topic.

PORTING FIXES
-----------------------------------------------------------------------

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B01-hppa-fixes.patch

   This is a compound patch containing many different hppa/parisc fixes
   Authors:
     Gerrit Pape <[email protected]>,
     John David Anglin <[email protected]>
     Helge Deller <[email protected]>
     Christian Seiler <[email protected]>

   Contains:
     semctl.S/semget.S/semop.S: hppa has direct syscalls, not __ipc
     start.S: use exit instead of _exit so stdio streams are flushed on
              exit
     include/signal.h: make sure signal definitions match the current
                       kernel source
     include/errno.h: make sure errno definitions match the current
                      kernel source
     {f,}truncate64.S: fix calling convention for these specific
                       syscalls
     select.S: when you unified the select syscalls after my previous
               patch series, you removed all select.S files because the
               logic is now more generic. For all other architectures
               this was correct, but on HPPA the select syscall needs
               to be defined via syscall5() instead of syscall().
               Restore the old parisc/select.S.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B02-ppc-gamma.patch

   Patch author: Gerrit Pape <[email protected]>

   This has been in Debian for at least 10 years and the gcc bug it
   works around on ppc (32bit only IIUC) is still not fixed. :-(

   I've added a comment explaining the details and linking the gcc bug
   report. Without that patch, dietlibc doesn't compile on powerpc32.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B03-ARMv7-regression.patch

   Patch author: Christian Seiler <[email protected]>

   This fixes the regression on ARMv7 that I reported in:
   http://thread.gmane.org/gmane.linux.lib.dietlibc/1814/focus=1821

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B04-TLS-setup.patch

   Patch author: Christian Seiler <[email protected]>

   This cleans up the TLS setup code for a lot of platforms. One of the
   patches I sent a while back that you applied fixed a compiler
   over-optimization on powerpc by using explicit assembly for setting
   the register instead of relying on direct assignment (addi %0,%1,0).
   Problem is that the over-optimization now occurs on all platforms,
   and I really don't want to research how to correctly write the
   equivalent of mov on each of them. Fortunately, if you declare the
   fixed-register variable to be global in the file, gcc will not
   optimize away the code (yay!), so we can simplify a lot of it and
   remove the previous ppc32-specific hack.

   Additionally I've researched how to set the TLS register on hppa and
   added that to the code as well. I also added a comment because it is
   really not trivial to understand wtf the code actually does and why
   it works... Since I'm not an expert on hppa, I asked Helge Deller
   (hppa porter) for comments on this TLS setup, and he said the code
   is correct.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B05-strlen-big-endian.patch

   Patch author: Christian Seiler <[email protected]>

   This is actually highly non-trivial: on big endian systems, the word
   based strlen() is actually not correct in some corner cases. This is
   actually the reason why Thorsten Glaser patched out the fast
   versions in the first place in Debian, because from what I gather
   from the Debian package's git history, it appears he thought it
   fails because of out of bounds access.

   In reality, it's not the out of bounds access, but far more subtle:

   Starting with e.g. word == 0x01000101, if we apply the operation
   (word - 0x01010101u) &~ word;
   we arrive at 0xfeff0000. Here we can see that the least significant
   bytes don't have the bit 0x80 set, which indicates to the code that
   handles the final word that there weren't any NUL bytes there.
   However, on the most significant byte we see some "spillover" from
   the fact that the word is smaller than the magic string, so it does
   have the bit 0x80 set "incorrectly", which will make the code taking
   care of the final word think that the first byte of the final word
   was NUL on BE systems, even though it isn't, causing wrong results.
   Note that if word > magic, e.g. if you have word == 0x02000101, this
   does not happen anymore, as the same operation will give 0x00ff0000,
   which will make everything work properly. On LE systems this is not
   a problem, as the bytes that come before the _actual_ NUL byte are
   the LSB, which are treated properly even there, so we don't need to
   have a special case for LE.

   I thought about it for a while and haven't come up with a nice bit
   operation way of handling this, so I just added a check and a simple
   loop for this corner case on BE.

   Without this patch, strlen("\001") will return 0 instead of 1 on big
   endian systems, such as mips or powerpc. (If the string is aligned.)

   strcpy/strcmp are NOT affected, as they only use the logic to detect
   if a NUL byte is present at all in the word, but then use an
   explicit loop to treat the last word.

   Note: this patch only applies trivially on top of the valgrind patch
   but the changes should be mergeable without the valgrind patch.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B06-pie-install.patch

   Patch author: Christian Seiler <[email protected]>

   This is trivial again: start-pie.o is only built on x86_64 at the
   moment and shouldn't cause "make install" to fail on other
   platforms.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B07-VPATH.patch

   Patch author: Christian Seiler <[email protected]>

   Another trivial patch: when you split start.o and start-pie.o, this
   broke mipsel, because you explicitly referenced $(ARCH)/start.S,
   which doesn't exist on mipsel. This patch makes Makefile revert to
   using the VPATH logic it previously used to find start.S - so on
   mipsel it will now correctly find mips/start.S again.

 https://gist.githubusercontent.com/chris-se/e01aa2cda9e8b75943e7610a7f3d71ec/raw/cdf16a760ef13dc40e9e3c02e634786361ae5053/porting-B08-sparc64.patch

   Patch author: Christian Seiler <[email protected]>

   sparc64 builds failed because struct ucontext on sparc64 doesn't
   appear to have a uc_stack member, making makecontext.c fail with a
   compiler message. I've adjusted the contents of struct ucontext in
   include/sys/ucontext.h so that it matches glibc on sparc, so the
   compiler is able to compile the routine.

   This will make builds succeed again on sparc64. This doesn't
   actually implement makecontext, which isn't implemented on most
   archs, and is thus not usable, but it does make sure that dietlibc
   build doesn't fail for something that was never supported before on
   the same platform.

UPCOMING STUFF (NOT INCLUDED HERE)
-----------------------------------------------------------------------

 - I do want to get powerpcspe working again (software floating point
   emulation, see the Debian bug that Thorsten Glaser forwarded to this
   list), but I need to have access to a proper environment first,
   which is more difficult than I expected. Don't know when that will
   happen.

 - I've ported dietlibc to ppc64el (release architecture for Debian 9,
   the little endian sibling of ppc64, although the function call ABI
   is completely revamped), but am still waiting on responoses from
   ppc64el people to look over it before I'm comfortable sending this
   here officially. But in principle it's done (no PIE/PIC/dynamic
   linking though), will probably send a separate patch tomorrow or so.

 - I've started looking at mipse64el (probable release architecture for
   Debian 9) and will look into porting dietlibc there. Apart from
   getting a qemu chroot running, I haven't done anything there yet, so
   no idea if I'll be able to get this done. The ppc64el stuff was both
   easier and more complicated than expected.





Anyway, as always, I'd be very grateful if you could include all of
these patches upstream.

Regards,
Christian