ira for Windows
Hi
I came across C source code for IRA and tried to compile it for windows/MinGW. I fixed a couple of issues (the most vicious one being a bug of the program which makes it crash on Windoze systems when you open a binary file in text mode ("r" not "rb")) and the program seems to work perfectly. I'd like to improve it a little bit, particularly in the "error message" area, and at some point fully understand the program one day and be able to add new features. Anyone interested by that? I heard Frank Wille is in the area. I don't want to steal work from anyone. I'm OK to maintain the tool, but if the legitimate owners/coders want to take it back, it's perfectly fine regards |
Quote:
I thought about updating IRA at one point also but found the code to be difficult to read and I'm not very good at C. I wanted to add floating point and mmu support. I ended up updating the old ADis disassembler because the source is so much easier and it already supported fpu and mmu instructions (except 68060 which I added). IRA and ADis both have their strengths and weaknesses. Frank has probably already cleaned IRA of many of the endian problems where ADis would likely have problems as I have done nothing to try and fix these but the program with source is here if you want to play with it... http://www.heywheel.com/matthey/Amiga/ADis.lha I compile it with GCC. Let me know if you find any bugs or want to do something with it. |
Quote:
Quote:
Quote:
Quote:
Some new features: - basereg support - no longer depends on PhxAss, but also supports vasm, Devpac, etc. - directive TEXT to define text regions - directives JMPB, JMPW, JMPL for jump/pointer tables - directive PTRS to define a pointer in binary mode - directive NOPTRS to force a misdetected pointer into data (binary mode) - many new friendly warnings and lots of bug fixes Quote:
IRA is free and everybody is welcome to contribute changes. When you want to work more frequently on the IRA source I could even give you CVS access. Just contact me. |
I'm a bit lost now. I have v2.09 and disassembling FPU instructions just don't work, even in 68040 mode. look at this atan func:
Code:
@atan: |
Quote:
ira.readme? Under new features for 2.09: Code:
- Support for 68060 instructions (except FPU). Quote:
|
thanks for clarifying. Support for 68060 except FPU made it look like other FPU instructions were there.
Hoping this is getting implemented some day. |
BTW I tried to disassemble some executables (TFX for instance) and got a lot of errors like
Code:
Watch out: prgcounter(00073250) > nextreloc(0002b1f0) Code:
BNE.W LAB_2AD4 ;53486: 66000348 |
Did you get these errors from the beginning, or at some point after modifying the config file? My guess would be that a region-specification in the config file is wrong, which makes the program counter skip a reloc position.
If you want, please send me an example (program file, config file, options used) by mail. |
I never use a configuration file. (yeah, i know, it's bad).
The TFX executables seem to have been "doctored" with this crap "hunk wizard" and they're probably at fault. They don't even work when running them... reloc corrupts the code... link to them https://is.gd/A6yk2T But I have seen others, which work. I don't remember which one they were but I'll contact you all right. |
Quote:
|
hexedit one of the "new" executables (and also the original TFX.040 one), at start there's this string:
Quote:
|
Indeed, I can confirm Bruce's observation. tfx.020 is ok, but tfx.030 seems corrupt. The relocation table is correct until the 3089th entry, which points to code-offset $421f0. The rest is nonsense or at least shifted by two bytes.
Maybe IRA should behave better in this case (I even had segfaults under NetBSD) and output more understandable error messages, but in any case there is not much it can do with this reloc table. ;) |
I tried the 020/030 executables in ReSource and had no problem disassembling them both. Hunk structure appears to be OK too at first glance.
|
3089th entry was irrelevant, as IRA sorts them. But when looking at the tfx.030 file, you will see the reloc-offsets for adding the base address of section #1 ($00000001 at $70560) here:
Code:
00070560 00 00 00 01 00 04 21 f0 00 04 22 20 00 04 2a 98 |......!..." ..*.| Code:
000421ea: 5240 addq.w #0x1,d0 |
problem is that once loaded using the OS, the code is corrupt by the relocs. I have proper BRA at some point which is replaced by trash once loaded & relocated.
I'm pretty sure that the devs applied some custom strip or hunk merging program (this crap Hunk Wizard) that corrupted the relocs. |
Quote:
Quote:
|
It's probably a case of "dev version works so I wrap it in my special process of stripping, etc."... and destroy the exe in the process. They never tested the final executable if you ask me.
I can confirm that the .020 version loads ok (needs FPU btw) even if processed by Hunk Wiz-shit-hard. The same one which doesn't display reloc warnings :) Maybe we could reassemble the code if we can fix the EXT_XXXX (with values like $453DC) that are in fact reloc offsets. That would require some heuristics, and not sure it would work for 100% of the mistakes. Or figure out what the bug is and if it's reversible. |
for missing FPU instructions, at least I can use python post-processing on IRA output (for labels that are called with BSR/JSR for instance) and use capstone (https://www.capstone-engine.org/lang_python.html):
Code:
atan: EDIT: capstone seems to fail on stack-related instructions. WinUAE disassembles as: Code:
FMOVE.X FP7,-(A7) |
Quote:
I doubt that a 030-version would give you so many advantages over a 020-version to make it worth the effort. |
|
All times are GMT +2. The time now is 08:17. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.