I wouldn't call the 0x0f thing a bug. It is a byte oriented op which only effects the LSB of the operand. So the disassembly is technically correct IMO.
On Sat, Nov 15, 2008 at 9:11 PM, pancake <[EMAIL PROTECTED]> wrote: >> Finally I decided to spend some time playing with radare :) This was >> on my TODO for a long time. >> >> Anyway, I have a few notes after some short usage time: >> >> 1) Building from sources using ACR (i.e. ./configure ... ; make) >> always fails on my Ubuntu (Hardy) system while compiling grava (it >> cannot find some GTK headers and also some GUI headers, even though I >> used --without-gui in configure). I had to fiddle with CFLAGS to make >> it build properly. > > Mmh, do you have vte-dev and gtk-dev ? there are no more dependencies for > the gui. But i will have to drop the vte dependency probably. > > Can you provide me some feedback of the errors? I had no problems with > any of my boxes :/ > >> 2) I tried a simple session with /bin/ls. Steps followed: >> >> - set .radarerc to: >> >> eval scr.color = true >> eval asm.syntax = intel >> eval file.analyze = true >> eval file.id = true >> eval file.flag = true > > its ok > >> - start radare with "radare /bin/ls" >> - disassemble with "pd". Here are the first lines of what I get: >> ; [13] 0x08049a80 size=00066748 align=0x00000010 r-x .text >> .......... >> >> Note the instruction at 0x08049A85. While on radare it translates to >> "and esp, 0xf0", on objdump (and HT) it is "and esp,0xfffffff0". >> Also note the instruction at 0x08049A9C. While on radare it is "call >> 0x8049635", on objdump/HT, it is "call 0x8049630". > > Yeah the 0xf0 is a bug reported in TODO. But I'm now investigating about the > source of this problem in udis86, I will hopefully push a fix for this > before monday.. but upgrading udis86 doesnt seems to be easy. And we should > probably need to wait for the upcomming "libr" to handle this properly. > > These bugs will force me to release a 1.1 :) > > The call bug it is fixed in the mercurial repo (thanks Nibble for the fast > response :) > >> I'm using radare 1.0. >> >> Keep up the good work! > > Thanks for the feedback! Nibble is looking to fix these bugs, and I hope to > have the 0xf0 bug fixed soon. Let see if its fixed in udis-1.7 or it was just > a bug in my integration or what the fuck :) > > I have uploaded a new snapshot at > http://www.radare.org/get/radare-20081116.tar.gz > > But I recommend you to always check from the mercurial repository. > > Enjoy! > > --pancake > _______________________________________________ > 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
