I've been looking into the problem with mpn/x86_64/fat/fat_entry.asm
I misunderstood how this works. The macro FAT_ENTRY defines functions
such as __gmpn_add_n, etc. All this function does is jump to the
address in the cpuvec_t (assuming these have been set up).
Initially however, the addresses in the cpuvec_t are set to point to
functions of the form __gmpn_add_n_init. Each such function is defined
by the macro FAT_INIT (also in the file fat_entry.asm). Each of these
init functions simply calls CPUID and figures out which version of the
relevant function is the right one for that processor, e.g.
__gmpn_add_n_amd64 or __gmpn_add_n_core2, etc. It places the pointer
to the correct function into the cpuvec_t then jumps to that function.
So when external code first calls __gmpn_add_n, it looks in the
cpuvec_t and finds a pointer to __gmpn_add_n_init which detects the
CPU and places the correct function pointer into the cpuvec_t for next
time. Then it jumps to that pointer and executes the real mpn_add_n
function.
The next time external code calls __gmpn_add_n, the right function
pointer is already there, so it just jumps straight to that.
Now here's the thing. If I remove the "jump to address listed in the
cpuvec_t" and just have it return instead, in the __gmpn_blah_n_init
functions (by changing the FAT_INIT macro), then the test code no
longer segfaults (though it does of course fail).
But here is what happens in that instance. The test code calls
__gmpn_add_n. This looks in the cpuvec_t and jumps to the function
pointer listed there. But this is the a pointer to the function
__gmpn_add_n_init. That function puts the "correct" address in the
cpuvec_t, which it then doesn't call (because I modified it to return
instead). So absolutely everything works without segfault, except
calling the real mpn_add_n function.
But that means that there can only be two possibilities. Either the
address of the real mpn_add_n function is computed incorrectly, or
there is something wrong with the real mpn_add_n function. The latter
seem unlikely given that it works for a non-fat build. So somehow
computing the address is incorrect.
But the function which stuffs this address into the cpuvec_t is
__gmpn_cpuvec_init. Specifically it calls a macro such as
CPUVEC_SETUP_amd64 (depending on the architecture detected by the
CPUID - which I have verified works).
But here is that MACRO:
#define CPUVEC_SETUP_amd64 \
do { \
decided_cpuvec.mul_karatsuba_threshold = 29; \
decided_cpuvec.mul_toom3_threshold = 137; \
decided_cpuvec.sqr_karatsuba_threshold = 62; \
decided_cpuvec.sqr_toom3_threshold = 186; \
decided_cpuvec.add_n = __gmpn_add_n_amd64; \
decided_cpuvec.addmul_1 = __gmpn_addmul_1_amd64; \
decided_cpuvec.copyd = __gmpn_copyd_amd64; \
decided_cpuvec.copyi = __gmpn_copyi_amd64; \
decided_cpuvec.mul_basecase = __gmpn_mul_basecase_amd64; \
decided_cpuvec.sqr_basecase = __gmpn_sqr_basecase_amd64; \
decided_cpuvec.sub_n = __gmpn_sub_n_amd64; \
decided_cpuvec.submul_1 = __gmpn_submul_1_amd64; \
} while (0)
Not much can go wrong there. Note decided_cpuvec is local to
__gmpn_cpuvec_init, but at the end of the function it copies
everything over into the cpuvec_t actually used by the function calls
(spoken about above).
So in short. I have no frigging clue why the code doesn't work!
Bill.
2009/1/19 Bill Hart <goodwillh...@googlemail.com>:
> For the time being I'll just assume that config.guess will return
> mingw64 instead of mingw32. If that is not the case, we can make it so
> when you figure out how to tell.
>
> Bill.
>
> 2009/1/19 mabshoff <michael.absh...@mathematik.uni-dortmund.de>:
>>
>>
>>
>> On Jan 19, 5:45 am, "Case Vanhorsen" <cas...@gmail.com> wrote:
>>> On 1/19/09, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>
>>>
>>>
>>> > Hi Case,
>>
>> Hi,
>>
>>> > can you run ./config.guess for us on your machine (it is in the main
>>> > directory of the source tree for MPIR). You may need to set
>>> > permissions first by doing chmod 755 config.guess
>>>
>>> $ ./config.guess
>>> core2-pc-mingw32
>>>
>>> > You're right. It isn't fully figuring out that it needs to be doing 32
>>> > bit assembly on this machine. Probably we need to recognise that it is
>>> > mingw and force it to use ABI=32 throughout.
>>
>> Note that Mingw has a 64 bit port, so the assumption Mingw -> 32 bit
>> build no longer holds. Unfortunately I am not sure how to properly
>> identify a 64 bit MinGW build. If I find out I will let yo know since
>> I have meant to start playing with it more for a while.
>>
>>> > Bill.
>>
>> Cheers,
>>
>> Michael
>>
>> <SNIP>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
