ira for Windows

[jotd]

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

[matthey]

Originally Posted by jotd

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

You should send Frank (phx on EAB) the fix. He is good about answering his e-mail even if he misses seeing a thread. Did you start with the latest source on Aminet? Frank has updated it recently. Frank is currently making a pretty big change to vasm and he can disappear for a while.

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.

[phx]

Originally Posted by jotd

I came across C source code for IRA and tried to compile it for windows/MinGW.

Which source? Tim's original V1.05 source doesn't really work on anything else than an Amiga. Last year I started to clean the source and made it portable (Ilkka Lehtoranta already did some work to clean it from SAS/C specific code before). The current version on Aminet (including source) is V2.05.

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"))

Yes, the last point was already fixed in V2.01. I didn't notice before, because I did my little-endian tests on NetBSD/i386.

and the program seems to work perfectly.

Hard to believe, when you are really using the old source.

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.

The source is not pretty indeed. When adding new features, I tried to understand the source by using a debugger.

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

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

There is always enough work for more than a single person.
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.

[jotd]

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:

@atan:
	DC.W	$f227			;4f312
	BMI.S	LAB_2558		;4f314: 6b80
	DC.W	$f200			;4f316
	BCLR	D1,D0			;4f318: 0380
	DC.W	$f200			;4f31a
	DC.W	$1c0a			;4f31c
	DC.W	$f21f			;4f31e
	CHK.W	D0,D5			;4f320: 4b80
	RTS				;4f322: 4e75

68040 comes with fpu so why doesn't it disassemble it? was that part lost as I read somewhere?

[phx]

Originally Posted by jotd

I'm a bit lost now. I have v2.09 and disassembling FPU instructions just don't work

Did you read

ira.readme

? Under new features for 2.09:

- Support for 68060 instructions (except FPU).
- Support for MMU instructions.

I admit this is confusing, as all directives and options to enable FPU reassembly are already present, but Nicolas Bastien just worked on the missing 060 and MMU instruction during the last years.

was that part lost as I read somewhere?

Yes, there was an IRA V1.xx release (Amiga-only) during the mid-90s which already supported FPU instructions. But the source was lost. So our porting effort had to start with the V1.05 sources.

[jotd]

thanks for clarifying. Support for 68060 except FPU made it look like other FPU instructions were there.

Hoping this is getting implemented some day.

[jotd]

BTW I tried to disassemble some executables (TFX for instance) and got a lot of errors like

Watch out: prgcounter(00073250) > nextreloc(0002b1f0)
... lots of others
P1 Missed bad reloc addr $0002b1f0!

Checking the code I see that some relocs have been zapped. Those EXT_xxxx can't be right

	BNE.W	LAB_2AD4		;53486: 66000348
	MOVEQ	#0,D0			;5348a: 7000
	MOVE.B	EXT_066e,D0		;5348c: 103900073250  missed reloc
	MOVE.W	D7,D1			;53492: 3207
	EXT.L	D1			;53494: 48c1

I wonder if the OS manages with those (I've met this case a few times). Interested to get examples?

[phx]

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.

[jotd]

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.

[Bruce Abbott]

Originally Posted by jotd

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.

My disassembler seems to handle the 020 executable OK, but barfs on the 030 version. Before I try to figure what the problem is, can you provide any more information about this crap "hunk wizard"?

[jotd]

hexedit one of the "new" executables (and also the original TFX.040 one), at start there's this string:

Hunk Wizard V1.2 by Christian A. Weber

That's all I know. And also that it's crap. I'm going to analyse the executable structure to understand what's the problem.

[phx]

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.

[StingRay]

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.

[phx]

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:

00070560  00 00 00 01 00 04 21 f0  00 04 22 20 00 04 2a 98  |......!..." ..*.|
00070570  00 04 2a f8 00 04 2b 08  00 04 2b 32 00 04 2b 3a  |..*...+...+2..+:|

The following offsets, starting with $421f0, are definitely not in the correct position, when you disassemble the first section.

000421ea: 5240                      addq.w  #0x1,d0
000421ec: e240                      asr.w   #1,d0
000421ee: 323c 00a7                 move.w  #0xa7,d1
000421f2: 5de0                      slt     -(a0)
000421f4: 41ec 3d1e                 lea     0x3d1e(a4),a0
...
0004221a: 3180 6200                 move.w  d0,(0,a0,d6.w*2)
0004221e: 3030 6207                 move.w  (0x7,a0,d6.w*2),d0
00042222: 35a2 5240                 move.w  -(a2),(0x40,a2,d5.w*2)
...

[jotd]

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.

[phx]

Originally Posted by jotd

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.

Yes, I would expect that.

I'm pretty sure that the devs applied some custom strip or hunk merging program (this crap Hunk Wizard) that corrupted the relocs.

But did the program ever work?

[jotd]

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.

[jotd]

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):

atan:
0x1000:	fmove.x	invalid, fp7
0x1004:	fmove	fp0, fp7
0x1008:	fatan	fp7, fp0
0x100c:	fmove.x	invalid, fp7
0x1010:	rts

I'll sort out this "invalid" stuff, but otherwise it seems to do the work!

EDIT: capstone seems to fail on stack-related instructions. WinUAE disassembles as:

FMOVE.X FP7,-(A7)
FMOVE.X FP0,FP7
FATAN.X FP7,FP0
FMOVE.X (A7)+,FP7
RTS

so maybe with some manual/heuristic fixing... I'll try to see if I can't report a bug on capstone.

[phx]

Originally Posted by jotd

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.

I'm sure there are many more un-relocated offsets, which were not flagged by an EXT-symbol, because the reassembler didn't recognize them as an address. Everything can be done, though, provided you want to invest the time.

I doubt that a 030-version would give you so many advantages over a 020-version to make it worth the effort.

[Bruce Abbott]

Hunk Wizard V1.2 (Tool) by Christian Weber