Small IRA Tutorial

[hop]

Originally Posted by phx

Two hours later I fixed a similar bug with offsetting a symbol defined at section start (replacing

SECSTRT_n

). Make sure

ira_2.c

has date 13:58 CEST. I reuploaded the archive.

I certainly wouldn't have spotted that. I'll grab the latest archive thanks.

[hop]

Hi. I'm having trouble processing offset hunk files with

-config

and I'm not sure if this is user error or a bug.

Using WB1.3 Calculator as a test case, this works as expected:

ira -a -label=1 -radix=0 -compat=bi -preproc Calculator
ira -a -label=1 -radix=0 -compat=bi -config Calculator

However, if an offset is applied during preprocessing, then the second invocation of ira fails:

ira -a -label=1 -radix=0 -compat=bi -offset=$10000 -preproc Calculator
ira -a -label=1 -radix=0 -compat=bi -config Calculator

It seems to warn immediately upon entering

DPass1

(see below), before eventually crashing with read access vilolation

IRA V2.11 (May 16 2024)
(c)1993-1995 Tim Ruehsen (SiliconSurfer/PHANTASM)
(c)2009-2023 Frank Wille
(c)2014-2019 Nicolas Bastien


SOURCE : "Calculator"
TARGET : "Calculator.asm"
CONFIG : "Calculator.cnf"
MACHINE: MC68000
OFFSET : $00010000
codeAdrs: 0   codeAdrMax: 16
CodeArea[0]: 00010000 - 0001008a
CodeArea[1]: 000100a2 - 00010582
...
CodeArea[19]: 00011df0 - 00011df0
CodeArea[20]: 00011df4 - 00011df4


Watch out: prgcounter(00010000) > nextreloc(00000080)
Watch out: prgcounter(00010002) > nextreloc(00000080)
Watch out: prgcounter(00010006) > nextreloc(00000080)
...
Watch out: prgcounter(00010088) > nextreloc(00000080)
P1 Missed bad reloc addr $00000080!
Pass 1: 100%
Pass 2: correcting labels
Pass 2: writing mnemonics
0 adr=10000 This=0
0 adr=10002 This=0
0 adr=10006 This=0
...
0 adr=10088 This=0
0 adr=1008a This=0

Please could you let me know if this should work?

This is not a problem for -BINARY files.

Many thanks for any help with this.

EDIT: Passing

-offset=$10000

along with

-config

fixes this, but I thought the offset would be read from the config file.

EDIT2: This seems to be an ordering bug:

main()
    Init()
        ReadOptions()
            parse -OFFSET=<OFFSET> into ira->params.prgStart
        ReadAmigaHunkExecutable(ira);
            ExamineHunks()
                set ira->hunksOffs[] from ira->params.prgStart
                set ira->reloc.relocAdr[] <- ira->hunksOffs[i] + offset
        ReadConfig()
            Parse OFFSET directive into ira->params.prgStart

[phx]

Originally Posted by hop

This is not a problem for -BINARY files.

Yes, but only because BINARY files have no relocations attached.

EDIT2: This seems to be an ordering bug:

Indeed. But it cannot be ordered in a different way, because there are dependencies on parsing the input file first (like code- and data-regions, etc.).

I guess the easiest solution is to forbid the OFFSET directive in config files, as long as the input file type is not a raw binary. And don't let -preproc write OFFSET to config files, when the type is not binary. I fixed that now (still allowing OFFSET=0 for backwards compatibility).

For hunk-format executables you have to use the command line option. I wasn't even aware that it can be used for relocatable executable files.

[hop]

Thanks

Originally Posted by phx

Yes, but only because BINARY files have no relocations attached.

Of course

Originally Posted by phx

it cannot be ordered in a different way, because there are dependencies on parsing the input file first (like code- and data-regions, etc.).

I guess the easiest solution is to forbid the OFFSET directive in config files, as long as the input file type is not a raw binary. And don't let -preproc write OFFSET to config files, when the type is not binary. I fixed that now (still allowing OFFSET=0 for backwards compatibility).

I like the idea of all of the information required being inside the config file. Would it be possible to parse the OFFSET directive from the config file early, and the remainder later?

[phx]

Originally Posted by hop

Would it be possible to parse the OFFSET directive from the config file early, and the remainder later?

Nothing is impossible. I'm on holiday for four days now and will think about whether it is worth the effort. The feature to use OFFSET for relocatable executables seems rarely used. What is your use-case here?

[hop]

Originally Posted by phx

Nothing is impossible. I'm on holiday for four days now and will think about whether it is worth the effort.

Thanks very much - enjoy yourself and don't think too much about disassemblers!

Originally Posted by phx

The feature to use OFFSET for relocatable executables seems rarely used. What is your use-case here?

Recursive traversal analysis for an interactive disassembler. I've implemented a tool using an emulator-lite that recursively traverses the executable and automatically adds EQUs for LVOs and custom register offsets to the ira config. It's working really well In practice, the emulation register tracking doesn't need to be very accurate, because most code that uses the associated register indirect addressing modes set the address register nearby. This feature takes advantage of ira's -KEEPBIN to apply the relocations and perform a lightweight "load" of the relocated binary into working memory. With an OFFSET of zero, reads from 4 don't return the mock Exec lib base address as required because the program exists in this space, and similarly writes to exception autovectors stomp the code.

The tool is also handy for identifying "hidden" CODE areas such as exception handlers.

[copse]

Originally Posted by hop

Recursive traversal analysis for an interactive disassembler. I've implemented a tool using an emulator-lite that recursively traverses the executable and automatically adds EQUs for LVOs and custom register offsets to the ira config. It's working really well In practice, the emulation register tracking doesn't need to be very accurate, because most code that uses the associated register indirect addressing modes set the address register nearby. This feature takes advantage of ira's -KEEPBIN to apply the relocations and perform a lightweight "load" of the relocated binary into working memory. With an OFFSET of zero, reads from 4 don't return the mock Exec lib base address as required because the program exists in this space, and similarly writes to exception autovectors stomp the code.

The tool is also handy for identifying "hidden" CODE areas such as exception handlers.

As someone who has implemented a rough interactive disassembler this looks way better than what I came up with. Nice work! Any chance of an obs recording on the youtubes showing it in use highlighting the cool things it can do?

[hop]

Originally Posted by copse

As someone who has implemented a rough interactive disassembler this looks way better than what I came up with. Nice work! Any chance of an obs recording on the youtubes showing it in use highlighting the cool things it can do?

Thanks. I didn't actually implement the disassembler at the heart of the tool - that's ira. However, the tool has to re-decode the instructions to step through, so it's a strange situation.

A video is a great idea. I was just about ready to release this tool, but I really thought it needed some more automation to be really useful. Feature creep.

[paraj]

Looks very neat, and looking forward to trying it out! I've also played around with making a more advanced disassambler myself, and the lack of "recursive" code discovery in IRA once you go for config settings is by far my biggest issue.

[hop]

Originally Posted by paraj

Looks very neat, and looking forward to trying it out! I've also played around with making a more advanced disassambler myself, and the lack of "recursive" code discovery in IRA once you go for config settings is by far my biggest issue.

I'll share a build when this feature is reasonably stable. Releasing source code is more time consuming than I anticipated!

I wasn't planning on writing a 68000 emulator, but the code traversal benefits from it. I should probably swap it out for a tried and tested feature compete 680x0 one, but it's been fun.

The traversal algorithm needs a bit more work. At present it can both break out of loops early that need to complete (like memcpys), and get stuck in loops it needs to escape from (like waitrasters). Swapping the simple counters for some simple CPU/memory state tracking should hopefully fix this.

[jotd]

I always wanted to do this too (symbolic execution) since 2003 but never went through. If you have your own emulation layer, you could get rid of IRA altogether, as executing in "text" mode has its limitations. There's a very good lib called "capstone" that even has a python interface and which can disassemble a lot of processors. I've used it in a project for work on 68040 and it works.

To be honest, finding LVOs is often much easier, with some manual rework. I've written a tool (cheapres.py) which allows to find most of them by performing some lousy & cheap "symbolic" execution (run until RTS or JMP or BRA and keep track of the current A6 value), then you rework the IRA source and run again to find the remaining ones.

[hop]

Hi. I would not have liked to try this in 2003, when immediate mode GUIs were not available.

Originally Posted by jotd

If you have your own emulation layer, you could get rid of IRA altogether, as executing in "text" mode has its limitations.

This would certainly have benefits for live analysis - stepping out of ira's CODE areas, and self modifying code could be handled nicely. However, ira is a great tool. It provides a lot of features that I would have to re-implement. And it has great portability, allowing users to analyse at speed on PC/Mac/Linux, then continue on a real Amiga using the same files if they wish.

Originally Posted by jotd

There's a very good lib called "capstone"

Thanks very much. Noted!

Originally Posted by jotd

To be honest, finding LVOs is often much easier, with some manual rework. I've written a tool (cheapres.py) which allows to find most of them by performing some lousy & cheap "symbolic" execution (run until RTS or JMP or BRA and keep track of the current A6 value), then you rework the IRA source and run again to find the remaining ones.

I've used your script a few times thanks! I did at first consider implementing LVO/equate finding as a post-processing step, but I wanted a solution that keeps everthing within the ira config file. The application contains a simple "Find Potential Equates" option that simply scans for instructions with the expected addressing mode and suggests actions to apply. I found that it was difficult to determine which library base address was in the register, especially when they had been stored and retrieved, so I started down the emulation path.

[phx]

Originally Posted by hop

Recursive traversal analysis for an interactive disassembler.

Ok. Had not much time during my holidays, but implemented that now. The config file is read twice. Once before reading the source file (for OFFSET) and once after that, for the remaining options.

Beta-archive is here: http://sun.hasenbraten.de/~frank/TEST/ira_211beta.lha

[hop]

Originally Posted by phx

Ok. Had not much time during my holidays, but implemented that now. The config file is read twice. Once before reading the source file (for OFFSET) and once after that, for the remaining options.

Beta-archive is here: http://sun.hasenbraten.de/~frank/TEST/ira_211beta.lha

Thank you very much. The changes look good (although I can't really follow the indentation and braces changes in ReadConfig ) and this seems to be working fine. I've removed the workaround that required the user to manually re-enter an -offset when processing hunk files with a config.