It is easiest if you put the builds online somewhere and open an issue referencing them. Then John and Doug can add them to the dll directory here: http://downloads.factorcode.org/dlls/ That the files you have built are smaller than the existing ones can be good or bad. I've found that it is often hard to control what dependencies VS will add to dlls you build. Sometimes it will decide to link to debug libraries and such. But you can check that with the excellent depends.exe utility: http://www.dependencywalker.com/
2016-11-25 9:22 GMT+01:00 Alexander Ilin <ajs...@yandex.ru>: > Thank you, John, that was very helpful! > >> P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit >> libudis86 is supported on other OS's. > > I have found the sources here: https://github.com/vmt/udis86 > > I happen to have VS2010, so I managed to build both 64- and 32-bit versions > of the DLL, v1.7.2. I can contribute those if you tell me the way. > BTW, for some reason my 64-bit build DLL file is smaller than the one at > http://downloads.factorcode.org/dlls/64/ > Maybe that's good. > > Anyway, when testing the thing under 32-bit I found an issue, of which I'm > not sure whether it's ours or theirs: > > IN: scratchpad : test2+ ( n -- n ) 2 + ; > IN: scratchpad \ test2+ disassemble > 083c2c10: a300106907 mov [0x7691000], eax > 083c2c15: 83c604 add esi, 0x4 > 083c2c18: c70620000000 mov dword [esi], 0x20 ! --------> This should be > 0x02 > 083c2c1e: a300106907 mov [0x7691000], eax > 083c2c23: ba2d2c3c08 mov edx, 0x83c2c2d (test + 0x1d) > 083c2c28: e903465bff jmp 0x7977230 (+) > 083c2c2d: 0000 add [eax], al > 083c2c2f: 0000 add [eax], al > 083c2c31: 0000 add [eax], al > 083c2c33: 0000 add [eax], al > 083c2c35: 0000 add [eax], al > 083c2c37: 0000 add [eax], al > 083c2c39: 0000 add [eax], al > 083c2c3b: 0000 add [eax], al > 083c2c3d: 0000 add [eax], al > 083c2c3f: 00 invalid > > The same issue is present in the 64-bit build of the libudis86.dll > downloaded from http://downloads.factorcode.org/dlls/64/ > > It can also be reproduced using their command-line client: >> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x > 0000000000000000 a300106907 mov [0x7691000], eax > 0000000000000005 83c604 add esi, 0x4 > 0000000000000008 c70620000000 mov dword [esi], 0x20 > All three lines of the above output have half-bytes swapped in the mnemonics > (0x20 instead of 0x2, 0x4 instead of 0x40, etc.). > > This begs the question: do we supply bad data to the disassembler, or does > disassembler misinterprets what we give it? > > ---=====--- > Александр > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- mvh/best regards Björn Lindqvist ------------------------------------------------------------------------------ _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
