Perl FR Disassembler
Very nice! My Perl version doesn't yet print data in other than hex and ASCII.
Does your disassembler handle subroutine names?
- I haven't implemented symbols yet; I'll probably get to that next week, along with cross-referencing. I intend to have an option like -s address=name to specify particular names, and generate internal labels for other addresses. kps 04:20, 7 November 2007 (UTC)
- I have the option to specify a symbol name, but the subroutine naming is automatic unless another name is specified (only implemented when the CALL address is constant, as above). Also, I have an option to specify a comment for an address K10dfreak 14:53, 7 November 2007 (UTC)
I also took the liberty to change the appropriate ST/LD instruction names to PUSH/POP.
- I did likewise (also for LDM/STM), along with changing the '2' shifts (e.g. LSL2 #5 -> LSL #21) and using AC, FP, and SP for R13-R15... all optional, of course. kps 04:20, 7 November 2007 (UTC)
- Good idea about the '2' shifts -- I also renamed R13-15 K10dfreak 14:53, 7 November 2007 (UTC)
P.S. I also wondered how to upload a binary file, and had hoped there was a better way than pretending it was an image, but I couldn't find one.
I tried to run DFR v1.1 to check a jump address, but I couldn't get it to work. Could you tell me the branch address for the BNE:D instruction at 0x10545310? I've got it branching to 0x1054531e, which is the middle of an LDI:32 instruction, and can't be right.
- I think you had the sign of the offset wrong there.
10545310 F3FA BNE:D 0x10545306
- Right, thanks. Fixed. K10dfreak 19:46, 9 November 2007 (UTC)
Re the DFR problems: It compiled OK, but crashed as soon as I ran it with no arguments. (First it complained about "too many input files" even when I had specified none. Then I hacked it past this and it crashed immediately in initialize() because char *s is used before it is initialized. Then I fixed this and it gave a bus error somewhere deep in a vfprintf() routine. Then I gave up.) I'm running on Intel Mac OS X with gcc 4.0.1. K10dfreak 18:29, 7 November 2007 (UTC)
- Ah, yes. Last minute changes just before going to sleep. I'll fix that this evening. Thanks for the report. kps 20:20, 7 November 2007 (UTC)
Version 1.02 still does this, any ideas why?: K10dfreak 12:47, 9 November 2007 (UTC)
> make cc -g -c -o dfr.o dfr.c cc dfr.o -o dfr > ./dfr FRDC162B.BIN dfr: too many input files
- I've thought of a possibility -- perhaps you've edited one of the startup option files (.dfrrc or dfr.txt) and it has been saved with CR as the line terminator in the old Mac fashion, and the C library doesn't recognize that as a line ending.
- Nope, that isn't it. I edited none of the files. Just un-zipped, copied the FW into the directory, compiled and ran. K10dfreak 14:38, 9 November 2007 (UTC)
- Can you check the line endings in dfr.txt? Maybe the unzipper changed them due to the '.txt' extension.
- The Mac doesn't mess with linefeeds, and most of the work I do is using Unix linefeeds anyway. But I double checked, and the linefeeds were Unix (0x0a). K10dfreak 19:21, 9 November 2007 (UTC)
- I just did some debugging in gdb, and find that somehow the values that are used in op->argv aren't the ones that are passed from the options(3, argv) call at line 2116. Unfortunately I don't have time now to figure out the exact problem. (I know you don't like Perl, but I should point out that I just spent more time debugging platform-dependent bugs than I have in 3 years of maintaining a very large Perl package that runs under dozens of operating systems.) K10dfreak 19:40, 9 November 2007 (UTC)
- I develop on a G4 10.3.9, and have run it on an x86 w/XP, but I'll try it on an Intel Mac on the weekend.