Hi Ive been thinking a while on this problem.. And end up in the same conclussion.
A small optimization (not using tenporary files) makes the code harder to read ans causes portability issues. As long as using nasm is an external dependency and having in mind that w32 will face other issues (no /dev..).. The only solution here is to rewrite the plugin using the portable funcions in r_util and delegate on temporary files to assemble stuff. As long as assembling is not usually a common task (not as much as disassembling) it does not matters much the speed.. And we have plans to enhace the native x86 assemblers so nasm will not be that important in 0.8. Do you mind to do this patch? Else I can do it if I get some free time Let me know. Thanks for pointing that issue :) On 13/03/2011, at 14:58, Glyn Kennington <[email protected]> wrote: > Hi, > The latest thing I've been breaking is the x86.nasm plugin. On > Ubuntu, "rasm2 nop" was giving the following error: > > Error running 'nasm' > Cannot assemble 'nop' > invalid > > It turns out that the way nasm and the plugin use here-documents works > with bash, but not with dash (the Ubuntu default) or busybox. > > I looked at the alternative method inside #ifdef __APPLE__ , and found > that, with a slight change, it works fine on linux too. So I think it > makes more sense just to use that method for both. (Though neither > worked for Windows with mingw32 - perhaps that should default to > x86.olly?) > > Patch attached. The change to libr/include/r_anal.h was necessary to > prevent a compile error when I tested on an old OSX box. > > Glyn > <nasm-plugin.diff> > _______________________________________________ > radare mailing list > [email protected] > http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
