I don't know what the bug is. Basically even a simple call to mpn_add_n fails.
The function is defined by expanding a macro in fat_entry.asm (the name mpn_add_n comes from a list of functions called CPUVEC_FUNCS_LIST in /mpn/x86_64/fat/x86_64-defs.m4). Essentially in fat_entry.asm, the macro immediately after FAT_INIT loops through each instruction in CPUVEC_FUNCS_LIST and enters an offset for it into the cpuvec. The macro after FAT_ENTRY loops through each instruction in CPUVEC_FUNCS_LIST (e.g. __gmpn_add_n) and defines a function of that name and sets that function up to simply call the function pointer in the cpuvec. What's not clear to me is which functions end up getting called if there is more than one possibility available for the given processor. In the case of an AMD64 chip the instructions in /mpn/x86_64 and /mpn/x86_64/amd64 are both valid. In fat.c the first lot of instructions are set up automatically. Then when the CPUID returns a value indicating that an AMD64 chip is available, the latter instructions are set up. I thought the whole idea of a fat binary was that at run time the fastest instruction for the chip is chosen. But it looks to me like once _gmpn_cpuvec_init is run, a decision has already been made based on the CPUID. I guess this makes a portable binary, which is certainly not faster than just building GMP on the system that you want to run it on (when function pointers will not be required). Anyhow, either the wrong pointers are being put into the cpuvec or the functions which call the function pointers are broken. That means the bug is between lines 56 and 154 of fat_entry.asm. But I've been over the code numerous times and don't see it. There must be something different about how these pointers are supposed to be computed or called on a 64 bit machine (I've fixed the obvious - the pointers should be 64 bits instead of 32). Anyone have any ideas? Bill. 2009/1/19 Bill Hart <goodwillh...@googlemail.com>: > I fixed cpuid and committed the change. Everything works right through > to the end of fat.c now. But some of the tests still segfault. > > Possibly some of the code in /mpn/x86_64 has bugs. It's never run, as > everything we build for is either core2 or amd64 if it is 64 bit. Of > course a fat binary will try to run it. > > Bill. > > 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> OK, I rewrote fat.c to work with the x86_64 cpus. This of course made >> it assemble fat_entry.asm which also requires some macros which were >> missing from x86_64-defs.m4. I fixed all this. >> >> Everything builds now, even make check. But make check segfaults. This >> will be because of the conversion of fat_entry.asm to 64 bit assembly. >> It's no doubt broken. It now needs to be rewritten properly. I >> especially expect that the functions cpuid and cpuid_available are >> broken. >> >> Bill. >> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >>> Could that be because they are not declared using the MPN_PROTO >>> business in gmp-impl.h as I mentioned in a post a couple of days ago? >>> >>> Bill. >>> >>> 2009/1/18 <ja...@njkfrudils.plus.com>: >>>> >>>> On Sunday 18 January 2009 21:25:10 Bill Hart wrote: >>>> >>>> runing strings on the libgmp.a I notice we have namespace pollution from >>>> all >>>> the new gcd stuff and mpn_modexact_1odd >>>> >>>> >>>> >>>>> I've checked that exactly the same files are compiled and linked when >>>>> working on a 64 bit machine as on a 32 bit machine. >>>>> >>>>> It looks like gmp-impl.h defines __gmpn_cpuvec as being external. I >>>>> was wrong about this being defined in fat.h, it is merely used there. >>>>> >>>>> The definition of __gmpn_cpuvec is actually in /mpn/x86_64/fat/fat.c. >>>>> This is defined unconditionally in there, so this file is somehow not >>>>> being linked into the library on a 64 bit machine. But I still don't >>>>> know why. >>>>> >>>>> Bill. >>>>> >>>>> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >>>>> > Nope that wasn't it. I fixed that problem and committed a fix, but the >>>>> > original problem still remains. >>>>> > >>>>> > Bill. >>>>> > >>>>> > 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >>>>> >> I think I have a clue. I can't get any of the tests in /tests/mpn to >>>>> >> work. They all bomb out. >>>>> >> >>>>> >> Looking in configure.in I see that for a 32 bit x86 build it puts >>>>> >> path="x86/fat x86" but for the 64 bit build I had path_64="x86_64 >>>>> >> x86_64/fat" with the directories in the opposite order. When I >>>>> >> autoconf and try to configure again it bombs out with: >>>>> >> >>>>> >> checking size of mp_limb_t... 8 >>>>> >> configure: error: Oops, mp_limb_t is 64 bits, but the assembler code >>>>> >> in this configuration expects 32 bits. >>>>> >> >>>>> >> So there is something inherently 32 bit about the files in >>>>> >> /mpn/x86_64/fat (which is not a surprise, as I copied them from >>>>> >> /mpn/x86/fat). >>>>> >> >>>>> >> Probably if we fix this it will work. >>>>> >> >>>>> >> Bill. >>>>> >> >>>>> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >>>>> >>> Yeah that is interesting. It might be a clue. >>>>> >>> >>>>> >>> The funny thing is, everything we need is defined in fat.h (which is >>>>> >>> created by configure). But fat.h is included by gmp-impl.h if >>>>> >>> WANT_FAT_BINARY is set, which it is if config.h is included, which it >>>>> >>> is if we don't have __GMP_WITHIN_CONFIGURE set, which is only set by >>>>> >>> configure itself when running. >>>>> >>> >>>>> >>> So I just don't see why it isn't picking up the requisite stuff from >>>>> >>> fat.h. >>>>> >>> >>>>> >>> Bill. >>>>> >>> >>>>> >>> 2009/1/18 <ja...@njkfrudils.plus.com>: >>>>> >>>> On Sunday 18 January 2009 18:59:46 Bill Hart wrote: >>>>> >>>>> did it get to addmul or lshift yet? >>>>> >>>> >>>>> >>>> I'm not entirely sure , but these are the only functions that give >>>>> >>>> errors eg make t-mul in the tests/mpz directory >>>>> >>>> >>>>> >>>>> I don't know what is different about them. They are done in a pretty >>>>> >>>>> similar way to addmul_1 and submul_1. >>>>> >>>>> >>>>> >>>>> Bill. >>>>> >>>>> >>>>> >>>>> 2009/1/18 <ja...@njkfrudils.plus.com>: >>>>> >>>>> > On Sunday 18 January 2009 18:45:35 Bill Hart wrote: >>>>> >>>>> >> That's likely because by the time those reference functions are >>>>> >>>>> >> used, the actual mpn functions referred to have already been >>>>> >>>>> >> tested. >>>>> >>>>> >> >>>>> >>>>> >> I don't think this can be the issue anyway, as everything works >>>>> >>>>> >> fine on a 32 bit machine. >>>>> >>>>> >> >>>>> >>>>> >> The actual error I got was a red herring anyway. The actual >>>>> >>>>> >> __gmp_cpuvec that we are after is defined in /mpn/x86_64/fat.c. >>>>> >>>>> >> Somehow it isn't picking this file up when building libtests.la >>>>> >>>>> >> or >>>>> >>>>> >> something in it. >>>>> >>>>> >> >>>>> >>>>> >> Bill. >>>>> >>>>> > >>>>> >>>>> > make[4]: `libtests.la' is up to date. >>>>> >>>>> > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -m64 >>>>> >>>>> > -o t-bswap t-bswap.o libtests.la ../libgmp.la >>>>> >>>>> > gcc -std=gnu99 -O2 -m64 -o .libs/t-bswap >>>>> >>>>> > t-bswap.o ./.libs/libtests.a >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so ../.libs/libgmp.so >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to >>>>> >>>>> > `__gmpn_sub_n' >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to >>>>> >>>>> > `__gmpn_cpuvec_init' >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to >>>>> >>>>> > `__gmpn_cpuvec' >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to >>>>> >>>>> > `__gmpn_add_n' >>>>> >>>>> > collect2: ld returned 1 exit status >>>>> >>>>> > >>>>> >>>>> > Only add and sub have a problem , not addmul or lshift , whats >>>>> >>>>> > different about them? >>>>> >>>>> > >>>>> >>>>> >> 2009/1/18 <ja...@njkfrudils.plus.com>: >>>>> >>>>> >> > On Sunday 18 January 2009 17:26:54 Bill Hart wrote: >>>>> >>>>> >> >> As a further data point make check works on cicero (which is a >>>>> >>>>> >> >> 32 bit x86 Pentium 4) with --enable-fat. So I don't see why it >>>>> >>>>> >> >> shouldn't work on a 64 bit machine. >>>>> >>>>> >> >> >>>>> >>>>> >> >> Bill. >>>>> >>>>> >> > >>>>> >>>>> >> > refmpn.c and refmpf.c have some referances to plain mpn_fn , >>>>> >>>>> >> > change these to refmpn_fn >>>>> >>>>> >> > >>>>> >>>>> >> > this clears up some of the errors.... >>>>> >>>>> >> > >>>>> >>>>> >> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >>>>> >>>>> >> >> > I've hacked up "support" for --enable-fat on x86_64. It's a >>>>> >>>>> >> >> > bit hackish (though I think the 32 bit fat support was >>>>> >>>>> >> >> > already hackish). >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > At this moment however, make check will not build, with >>>>> >>>>> >> >> > error: >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > ./.libs/libtests.a(refmpn.o): In function >>>>> >>>>> >> >> > `refmpn_mod_34lsub1': refmpn.c:(.text+0x1f3): undefined >>>>> >>>>> >> >> > reference to `__gmpn_cpuvec' >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > etc. Now refmpn.c #include gmp-impl.h which defines >>>>> >>>>> >> >> > __gmpn_cpuvec on line 3783 *provided* WANT_FAT_BINARY is >>>>> >>>>> >> >> > defined and set (see line 3753). The thing is, make requires >>>>> >>>>> >> >> > that to be set in order to build a fat binary in the first >>>>> >>>>> >> >> > place. Surely configure configures this the same for make >>>>> >>>>> >> >> > and >>>>> >>>>> >> >> > for make check. So I honestly don't know why make check >>>>> >>>>> >> >> > fails. If anyone has any insight into this, please let me >>>>> >>>>> >> >> > know. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > I'll now mention some of the more hackish aspects of getting >>>>> >>>>> >> >> > --enable- fat to work on x86_64: >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > * I removed the check for HAVE_HOST_CPU_FAMILY_x86 on line >>>>> >>>>> >> >> > 3753 of gmp- impl.h. This was hackish. Obviously configure >>>>> >>>>> >> >> > should not continue if fat binary is not supported on the >>>>> >>>>> >> >> > host cpu. It shouldn't be left until this point to determine >>>>> >>>>> >> >> > that. I did try to add a >>>>> >>>>> >> >> > HAVE_HOST_CPU_FAMILY_x86_64 flag, but for some reason I >>>>> >>>>> >> >> > couldn't get it to work. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > * I had to put a modified copy of yasm_mac.inc in /mpn and >>>>> >>>>> >> >> > /mpn/ x86_64. Now it inserts suffices on function names when >>>>> >>>>> >> >> > calling the macro GLOBAL_FUNC. Only when building a fat >>>>> >>>>> >> >> > binary does it refer to these copies of yasm_mac.inc instead >>>>> >>>>> >> >> > of the one in the root of the source tree, thus suffices >>>>> >>>>> >> >> > will >>>>> >>>>> >> >> > not be added for a normal build. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > * I had to copy /mpn/x86/fat/* into /mpn/x86_64/fat. But >>>>> >>>>> >> >> > note >>>>> >>>>> >> >> > that I have not defined any 64 bit family/model/stepping >>>>> >>>>> >> >> > values in the fake CPUID tables in fat.c as of yet. This >>>>> >>>>> >> >> > probably means that the fat binary which is build does >>>>> >>>>> >> >> > nothing. But someone can add the relevant CPUID values if >>>>> >>>>> >> >> > they feel so inspired. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > * Probably a fat binary build on x86_64 doesn't work on 64 >>>>> >>>>> >> >> > bit Windows (I'm not talking about MSVC here, but something >>>>> >>>>> >> >> > like Cygwin64 if and when it exists). because the filenames >>>>> >>>>> >> >> > with suffices are longer than the usual 8.3 format. I don't >>>>> >>>>> >> >> > know if this is a problem or not, but it might be. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > * Configure almost certainly can't find functions in >>>>> >>>>> >> >> > multifunction yasm assembler files implemented with macros. >>>>> >>>>> >> >> > It has no idea how to interpret the macro language of yasm. >>>>> >>>>> >> >> > Thus functions probably won't be picked up from >>>>> >>>>> >> >> > multifunction >>>>> >>>>> >> >> > files. Whilst we use macros, we currently have separate >>>>> >>>>> >> >> > files >>>>> >>>>> >> >> > for each of the macro'd functions, so this is actually not a >>>>> >>>>> >> >> > problem at present (it infers the function names from the >>>>> >>>>> >> >> > filenames alone if they are not actually implemented as >>>>> >>>>> >> >> > multifunction files). But it will break when we fix >>>>> >>>>> >> >> > multifunction support. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > Lots of other hacking was required to get this far. But the >>>>> >>>>> >> >> > above is the worst of it. I'll add it to a trac ticket for >>>>> >>>>> >> >> > someone with more patience than myself to fix. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > Bill. >>>>> >>>>> >> >> > >>>>> >>>>> >> >> > On Jan 15, 1:25 am, "Bill Hart" >>>>> >>>>> >> >> > <goodwillh...@googlemail.com> >>>> wrote: >>>>> >>>>> >> >> >> 2009/1/15 Bill Hart <goodwillh...@googlemail.com>: >>>>> >>>>> >> >> >> > The problem with --enable-fat on 64 bit systems is that >>>>> >>>>> >> >> >> > it >>>>> >>>>> >> >> >> > searches the 64 bit assembly directories for functions >>>>> >>>>> >> >> >> > but >>>>> >>>>> >> >> >> > sets the fat directories to the 32 bit x86 directories. >>>>> >>>>> >> >> >> > This can easily be fixed. Lines 1457-1476 of configure.in >>>>> >>>>> >> >> >> > need to be replicated for the following case statement >>>>> >>>>> >> >> >> > which deals with 64 bit machines, but with the correct >>>>> >>>>> >> >> >> > directories set. >>>>> >>>>> >> >> >> >>>>> >>>>> >> >> >> Actually this won't quite directly work. The reason is that >>>>> >>>>> >> >> >> in order to determine which functions it should include in >>>>> >>>>> >> >> >> the fat binary, it looks for PROLOGUE(mpn_fnname) in the >>>>> >>>>> >> >> >> assembly files. We don't use that macro in the x86_64 >>>>> >>>>> >> >> >> assembly code (which is in yasm format). >>>>> >>>>> >> >> >> >>>>> >>>>> >> >> >> We could fix this by modifying what it looks for >>>>> >>>>> >> >> >> appropriately on x86_64. We should be looking for >>>>> >>>>> >> >> >> GLOBAL_FUNC mpn_fnname instead. >>>>> >>>>> >> >> >> >>>>> >>>>> >> >> >> Bill. >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
