Actually, scrub that. It uses ELF-32. I'm trying objdump, though the Windows version doesn't seem to disassemble. :-(
Bill. 2009/12/5 Bill Hart <[email protected]>: > I believe the obj format that TCC uses is not the same as that MinGW > produces. So I don't think it will work. > > There can be subtle differences, too, say to do with the global symbol prefix. > > What I really need is an object disassembler for tcc, but I believe > one does not exist. > > Another option is for me to produce a .exe which only links that one > object file and inspect the assembly for that. There are lots of > disassemblers available for Windows, so this should work, I think, > provided the .exe is not too large. I think if you compile with > symbols it is easier to locate the relevant section, but it is not > something I have experience with. > > Bill. > > 2009/12/5 Cactus <[email protected]>: >> >> >> On Dec 5, 4:02 pm, Bill Hart <[email protected]> wrote: >>> I traced down precisely where the bug occurs. It is in the call to >>> mpn_divexact_by3 in the toom3 interpolation code. If I replace that >>> with a call to mpn_divexact_1 then it works fine. >>> >>> Under MinGW with the gcc compiler, on the same machine in Windows 32, >>> the bug does not occur. >>> >>> That leaves few options. >>> >>> 1) The assembly file is misassembled by tcc. >>> 2) There is a bug in the tcc linker. >>> 2) The assembly file has a bug which relies on uninitialised data >>> which just happens to be 0 on linux and in MinGW. >>> 3) The subtle differences in calling conventions between Windows and >>> Linux are biting me on this one file. >>> >>> I don't know how to check for 1, and consider it unlikely. An >>> assembler doesn't exactly have to do a whole lot. >>> >>> A linker bug might be more likely, but I have no idea how to check for >>> that either on Windows. >>> >>> Unfortunately there is no valgrind on any 32 bit machine I have access >>> to, so checking 2 is difficult. I will probably have to read the >>> assembly code extremely carefully. >>> >>> I can investigate 3, but I think there aren't enough arguments to the >>> function for this to be the issue. >>> >>> Bill. >>> >>> 2009/12/5 Bill Hart <[email protected]>: >>> >>> >>> >>> > I tried to replicate the error I was having with diveby3.asm with tcc >>> > on 32 bit windows, on linux, but no luck. On Cicero, which is a 32 bit >>> > linux pentium4, that particular file seems to work fine. >>> >>> > Apart from it being misassembled by tcc, I don't really have any good >>> > ideas. I checked that m4 is expanding it correctly. >>> >>> > There is no HAVE_NATIVE_mpn_divexact_by3 flag (at least none listed in >>> > config.h), so it can't be an alternative code path. This function is >>> > defined unconditionally for all archs. >> >> If the *.obj formats are compatible (as they might be on win32) you >> could take the *.obj for this file and link it into the 'other' build >> (both ways) and see if it still fails. >> >> The other thing I sometimes do is to use Agner Fog's excellent >> objconv.exe program to produce assembler source code for two *.obj >> modules that should be the same and then compare the resulting source >> code to see if they differ. >> >> Brian >> >> >> >> >>> >>> > Bill.- Hide quoted text - >>> >>> - Show quoted text - >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/mpir-devel?hl=en. >> >> >> > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
