Disassembler

[copse]

Using Resource under WinUAE, gets somewhat frustrating. I've been meaning to write my own disassembler for years, and finally got around to it. It's easier than I expected, but like any programming project there's so much that needs to be done.

It currently just loads and does raw disassembly of an Amiga executable. Still need to get "labels" working, follow branches to determine what to actually disassemble and what is data. Etc.

[prowler]

Nice work, copse!

[PeterK]

Hi copse,

why do you want to reinvent the wheel again?

Matthew Hey (alias matthey http://eab.abime.net/member.php?u=16145 ) is also already working on an improved version of ADis. Maybe, you could get in contact with him and work together.
http://www.heywheel.com/matthey/Amiga/ADis.lha
http://www.heywheel.com/matthey/Amiga/programming.html

[copse]

Originally Posted by PeterK

Hi copse,

why do you want to reinvent the wheel again?

Matthew Hey (alias matthey http://eab.abime.net/member.php?u=16145 ) is also already working on an improved version of ADis. Maybe, you could get in contact with him and work together.
http://www.heywheel.com/matthey/Amiga/ADis.lha
http://www.heywheel.com/matthey/Amiga/programming.html

If one reinvents the wheel, then one understands why the wheel is the way it is. Understanding why the wheel is the way it is, enables one to develop better wheels. Just using someone else's wheel means you have to accept all the flaws, and not know how to do anything about them.

My word! Next you will be asking why I would use goto when everyone knows it shouldn't be used

[PeterK]

Ok, I can understand your point of view that you prefer to learn writing a disassembler from scratch rather than fighting with other programmers concepts.

But, I guess you won't have to accept all the flaws of the current ADis as far as there are any in Matt's disassembler project. He has excellent knowledge about the 68k instructions and he has always an open mind for discussing things. So, don't hesitate to get in contact with him if he won't reply in this thread anyway sooner or later. I'm sure, he will welcome all your suggestions for improving the ADis disassembler. (Just don't know if he would rename the BRA or JMP instructions into a GOTO cammand ?

[TCD]

There's also http://eab.abime.net/showthread.php?t=51527

[copse]

Originally Posted by PeterK

Ok, I can understand your point of view that you prefer to learn writing a disassembler from scratch rather than fighting with other programmers concepts.

But, I guess you won't have to accept all the flaws of the current ADis as far as there are any in Matt's disassembler project. He has excellent knowledge about the 68k instructions and he has always an open mind for discussing things. So, don't hesitate to get in contact with him if he won't reply in this thread anyway sooner or later. I'm sure, he will welcome all your suggestions for improving the ADis disassembler. (Just don't know if he would rename the BRA or JMP instructions into a GOTO cammand ?

I actually looked at IRA, but there were numerous reasons that it wasn't suitable for me.

The licensing situation is unclear, as it is inherited code. When I say unclear, I mean it is important to me to be able to look at the license for it, and understand the repercussions. "It should be OK" is not good enough.

Also, I find the source code arcane and incomprehensible as to why it does what it does. I understand Matt inherited the code, so I in no way wish to assign the blame for this to him.

[copse]

Originally Posted by TheCyberDruid

There's also http://eab.abime.net/showthread.php?t=51527

Thanks for pointing that out. He's doing pretty well, with sections, local labels, "custom bases" as resource calls them, labels and full line comments and more.

Not sure how I missed that in "Today's Posts".

[matthey]

Originally Posted by copse

I actually looked at IRA, but there were numerous reasons that it wasn't suitable for me.

IRA is currently developed by Frank Wille with the latest released versions on Aminet. Although IRA is a pretty good disassembler with some very useful options, the C source code is poorly written (not Frank's fault). It also does not do FPU or MMU instructions which I wanted for a project. I (Matthew Hey that Peter kindly mentions) found ADis which had the functionality I wanted but lots of bugs too. Many are now fixed. The core instruction handling and disassembly works well now and I think readability and efficiency have been improved despite my amateur C skills. The source is worth taking a look at even if you don't use it. Use the link Peter provided as that is the latest version and it's not on Aminet. The code needs some updating to run on little endian processors. I know some of the problem points if you want to try making it support little endian with conditional compiling.

Originally Posted by copse

The licensing situation is unclear, as it is inherited code. When I say unclear, I mean it is important to me to be able to look at the license for it, and understand the repercussions. "It should be OK" is not good enough.

The licensing situation with ADis is very clear. It's open source with no restrictions by the original author and me so use as you wish. I would appreciate that you provide any bug fixes or improvements to possibly be added into a new version. If you release a significantly different version, then choose a different name. Ara's project looks promising also if you would rather go that route. ADis would need some work to make it ready for an editor with GUI like Resource. At that point, it would be kool to make it a debugger also.

[copse]

Ah, it was late and I was confused. When looking at existing disassemblers I looked at GNU binutils, AsmPro, WinUAE, IRA and ADis. ADis was probably the best, but to me its licensing situation was unclear. A clear licensing situation to me, is where it has MIT, GPL, BSD or a similar reliable license accompanying source releases. It might be sufficient for you to accept someone saying it is open source, with no restrictions, but unless that's provably in writing in all relevant source releases, I can only take it as hearsay.

But in the end, I think it is best to start from scratch. Having now written a disassembler, I have something I understand 100%.

[matthey]

Originally Posted by copse

Ah, it was late and I was confused. When looking at existing disassemblers I looked at GNU binutils, AsmPro, WinUAE, IRA and ADis. ADis was probably the best, but to me its licensing situation was unclear. A clear licensing situation to me, is where it has MIT, GPL, BSD or a similar reliable license accompanying source releases. It might be sufficient for you to accept someone saying it is open source, with no restrictions, but unless that's provably in writing in all relevant source releases, I can only take it as hearsay.

I agree that the license and copyright status of ADis are not 100% clear. I doubt there is any way to be sure that Martin Apel uploaded the last version to Aminet either. It's probably not a problem for a non-commercial product but maybe you are serious about making a disassembler .

Originally Posted by copse

But in the end, I think it is best to start from scratch. Having now written a disassembler, I have something I understand 100%.

Disassembling instructions is the easy part I think you will find. You will learn plenty programming it yourself. Good luck.

[copse]

Lots more work on this. If anyone has any pointers with regard to the relocation information I want, I'd appreciate it.

I've handled the HUNK_RELOC32, HUNK_DREL32 and HUNK_RELOC32SHORT relocations, but nothing else. I've also looked at a lot of code that parses hunks, and documentation that deals with hunks, and I've been unable to find clear information on hunk types like HUNK_RELOC8. Anyone got any solid leads on these? One piece of code just handled them the same as HUNK_RELOC32, but I believe that is wrong.

The UI toolkit I am using is starting to get in the way. On the plus side, the display is virtually generated, so there's no huge buffer that the user scrolls through. But there's no way do Resource-style markup, like inverting symbols that are in other hunks.

My symbol/label handling is the only existing code that I am unhappy with. It looks okay, but it is superficially done. Resource does it a lot more intelligently.

[Toni Wilen]

RELOC16/8 are linker object only, can't be used in executables.

There is also RELRELOC32 which is supported by AOS (afaik v39+ only) but it has buggy implementation which makes it totally useless. (Relative to relocation address instead of relative to beginning of hunk)

Check AROS rom/dos/internalloadseg_aos.c

[matthey]

This is a pretty good hunk reference on Aminet:

http://aminet.net/docs/misc/abfs.lha

An online hunk reference with some info not found elsewhere:

http://amiga-dev.wikidot.com/file-format:hunk

[copse]

Originally Posted by matthey

This is a pretty good hunk reference on Aminet:

http://aminet.net/docs/misc/abfs.lha

An online hunk reference with some info not found elsewhere:

http://amiga-dev.wikidot.com/file-format:hunk

The last link is actually mine. I've just now extended it with further information along the lines of what Toni intimated, based on going over the v31 dos.library disassembly someone (Don Adan?) posted elsewhere. I've copied/pasted what I did here, in case anyone else wants to scour it to clear up any odd assumptions.

I'd be curious to know why anyone would use HUNK_ABSRELOC16.

[phx]

Originally Posted by copse

I'd be curious to know why anyone would use HUNK_ABSRELOC16.

Nobody will ever use it. It makes no sense under AmigaOS, because your sections will rarely be relocated to an address between $ffff8000 and $7fff.

EXT_ABSREF16 references occur often in object files, but they are always refering to absolute external constants and never to an address in a section, so all of them can be resolved by the linker.

[copse]

Originally Posted by phx

Nobody will ever use it. It makes no sense under AmigaOS, because your sections will rarely be relocated to an address between $ffff8000 and $7fff.

EXT_ABSREF16 references occur often in object files, but they are always refering to absolute external constants and never to an address in a section, so all of them can be resolved by the linker.

Ah, that's very interesting, thanks.

[copse]

To make the frontend code more flexible and less Amiga/68k dependent, I wanted to start by adding support for other platforms that are also m68k-based. The easiest is of course the Atari ST, and the screenshot below is shows disassembly of a random PRG file.

Anyone got any handy links for other 68k executable file formats other than Amiga loadfiles and ST prgs? I've been struggling to find any for the Sharp X68000 platform.

[prowler]

Originally Posted by copse

Anyone got any handy links for other 68k executable file formats other than Amiga loadfiles and ST prgs? I've been struggling to find any for the Sharp X68000 platform.

Hi copse,

Here is a link to a page with downloads to help you get hold of some X68000 executables:
http://gamesx.com/wiki/doku.php?id=x...s_of_mdx_files

This is an X68000 hard drive image (129MB):
http://nfggames.com/users/eidis/X68000.zip

Which can be opened in Windows with DiskExplorer v1.69:
http://nfggames.com/users/eidis/editd169.zip
to get what you need.

[copse]

Originally Posted by prowler

Hi copse,

Here is a link to a page with downloads to help you get hold of some X68000 executables:
http://gamesx.com/wiki/doku.php?id=x...s_of_mdx_files

This is an X68000 hard drive image (129MB):
http://nfggames.com/users/eidis/X68000.zip

Which can be opened in Windows with DiskExplorer v1.69:
http://nfggames.com/users/eidis/editd169.zip
to get what you need.

Ah, sorry, should have been clearer. I want a document that describes the format. I can find existing code out there, and example files, but documentation of the format is eluding me. Thanks anyway!