On 25 Oct, 2009, at 13:48, Johnny Halfmoon wrote: > > top of the bill, as far as I know, is IDA pro. Simply amazing > product, with matching pricetag. Google-ing for 'arm disassembler' > will ofcourse yield some more results. > > http://www.hex-rays.com/idapro/
Thanks! I've downloaded the non-comercial .EXE and will give it a go whenever I get round to booting Windows :-) On 25 Oct, 2009, at 08:11, David Brownell wrote: > For low level debug, and of course understanding performance, > I certainly get familiar with the instructions. Even if I'm > no doing that, I make a point of looking at ASM output for > compiled functions before I call them "done" ... there will > often be some easily fixed stupidities causing code bloat. Oh indeed :-) The list of stupidities is frightening :-) My favourite short one is 0000003C SUB, R0, R0, #1 00000040 MOV R1, #0 00000044 CMP R0, R1 00000048 BNE 0x30 0000004C B 0x50 00000050 ... > If I need more information than I get from OpenOCD, I'll > generally use "objdump" to at least get the symbols. That > does a rude job of associating object code with source in > any sane optimization scenario though, so I rarely have it > go up a level and match the source. (That disassembler is > the same one GDB uses ...) > > >> The armv4_5 disassemble command is fine, in that it disassembles, >> but as I mentioned a while back, it doesn't produce what I would have >> written as an assembly code routine :-) > > It's not there to support source level debug, no; neither > for ASM source, nor for C source. > > What OpenOCD provides is what used to be called a "machine > language debugger". For that, the main criteria are to be > adequate and to work without all the infrastructure needed > by fancier debuggers (such as GDB). OK. I suppose what I'm doing at the moment, ie. looking at the STR9- comstick flash, WITHOUT having the source code, isn't that usual a task. I had a look at the objdump output (-D -b binary -m arm) and its markup seems to be limited to calculating PC relative addresses for you. The dumped flash file doesn't seem to have a symbol table, as far as I can tell. On 25 Oct, 2009, at 01:50, Igor Skochinsky wrote: > > I don't see the point of making an advanced disassembler out of > OpenOCD. I wasn't proposing that. > I think the main purpose of adding the routine was to do some > spot checks during debugging. In fact, it's probably not really > necessary once gdb interface was implemented, as gdb can do > disassembly itself. ... but not very advanced disassembly :-) > If you need to disassemble a lot of code "offline", it's much better > to use specialized tools such as objdump or IDA Pro or whatnot. OK. Thanks for the responses. I'm now clued up and happy :-) My 150 line disassembler produces more useful output than the GNU one, so it wasn't a total waste of time. But it won't be anything like as good as IDA Pro. Also, no one has said "why aren't you using the free ARM products you dunce!" so I don't need to go hunting for The Sensible solution. :-) --colin _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
