Re: [PATCH] Support powerpc64le-linux platform
Ulrich Weigand ulrich.weig...@de.ibm.com writes: Testing cpp symbols for ABI version makes me a bit nervous. Such things can easily get out-of-synch. It might be more resilient to check a generated object. Well, the _CALL_ELF check is what we use for all other packages that needed ELFv2 changes, starting from glibc ... So if that ever gets out of sync, we'll have bigger problems anyway. That's reassuring. :o) Is the setting of of a TOC pointer unconditionally really needed (presumably for a call from another shlib including the main program) even for leaf functions which also don't use the TOC? If a function does not use the TOC (either explicitly or implicitly e.g. because it performs a function call), then we do not need to set it up in the prolog. However, since there was just a single PROLOGUE macro, it seemed the safe course to set it always. Now, if we know for sure that none of the functions needs a TOC, we can omit it completely. Or else, we could introduce two versions of the PROLOGUE macro, and let each function choose the right one. We have for other machines allowed an optional 2nd argument for PROLOGUE. I'm not sure if this is really worth the effort though: it makes a difference only if the function is called externally (from another shared library or via function pointer). Aren't those routines mostly called locally anyway? Local calls will bypass the TOC setup automatically anyway. It will help time-critical end-user programs which call documented mpn functions directly. Some asm files do use the TOC (typically mode1o.asm, invert_limb.asm, mod_1_[1234].asm, gcd_1.asm). I'd suggest using PROLOGUE(fn,toc) for the latter functions, and PROLOGUE(fn) for other functions. For the v1 ABI, I assume we cannot be clever about this. Is there a way we could test powerpc64le-linux or the new abi? We try to have (automated) tests for every ABI which we claim to be supporting. Right now there is no base OS for powerpc64le-linux that you could install readily, and there's also no easy way to get a machine to run this on. I'm sure once we're a bit farther along, we'll try to make a powerpc64le-linux test machine available, e.g. in the GCC compile farm. I usually simulate GMP test systems. Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: [PATCH] Support powerpc64le-linux platform
Ulrich Weigand uweig...@de.ibm.com writes: this patch updates GMP to support the little-endian PowerPC64 platform (powerpc64le-linux). This requires two changes: - Update configfsf.guess/sub to current upstream versions. I think Niels volunteered to do that... - Change mpn/powerpc64/elf.m4 to generate appropriate assembler code for the new ELFv2 ABI. The relevant change here is that we no longer require function descriptors; instead, functions that use the TOC register need to provide a pair of global and local entry points. For more details, see the GCC patch messages here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01144.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html Tested using make check on powerpc64le-linux; in addition, we've been using this patch for a while when building GMP to use with the native GCC on the platform. Also, built and tested with no regressions on powerpc64-linux. Good! Comments: Testing cpp symbols for ABI version makes me a bit nervous. Such things can easily get out-of-synch. It might be more resilient to check a generated object. Is the setting of of a TOC pointer unconditionally really needed (presumably for a call from another shlib including the main program) even for leaf functions which also don't use the TOC? Is there a way we could test powerpc64le-linux or the new abi? We try to have (automated) tests for every ABI which we claim to be supporting. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: [PATCH] Support powerpc64le-linux platform
Ulrich Weigand uweig...@de.ibm.com writes: - Update configfsf.guess/sub to current upstream versions. We should definitely do that, independent of the other fixes. Please remind if we don't get to that within a week or so (I can't do it right away). - Change mpn/powerpc64/elf.m4 to generate appropriate assembler code for the new ELFv2 ABI. The relevant change here is that we no longer require function descriptors; instead, functions that use the TOC register need to provide a pair of global and local entry points. For more details, see the GCC patch messages here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01144.html http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html Looks sane to me (without understanding the fine details). Maybe Torbjörn has some comments. I'm not really familiar neither with how ABI variants are handled in GMP, nor with powerpc assembly. Would this be OK for GMP mainline? I think so. (I haven't submitted a GMP patch before; if there's anything else I should be doing to facilitate this process, please let me know!) We ask for FSF copyright assignments for all substantial changes. Yours is maybe borderline, but I think we'd still like to have some paperwork. We can arrange it off-list. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
