cg@ami-cg.UUCP (Chris Gray) (05/14/89)
I'm currently in the final phases of writing an AmigaDOS object file dumper/ disassembler. It consists of a shareable library to do the actual disassembly (to be used in a debugger also) and a file reader/dumper. It already does pretty much everything I need, but, for completeness, I'd like it to also handle all of the new hunk types that Lattice uses. The AmigaDOS technical reference manual describes hunk types 999 - 1011, 1013, 1014. Lattice will generate 1016, which I would guess is an a4-relative offset. Is 1015 used for anything? What about the new stuff for libraries? In HUNK_EXT's, I know of types 0 - 3, 129 - 132. Lattice uses 134, presumeably again for a4-relative stuff. Is 133 used? Could someone please send me a definition of all of the new codes so that I can make my dumper/disassembler as general as possible? With luck, it should be off to Bob Page sometime this week, or next weekend. Oh yes, it tries its best to do a fully symbolic disassembly, and it knows about the 68020, 68851 and 68881. It handles unlinked and fully linked files. Thanks. -- -- Chris Gray ..!alberta!myrias!ami-cg!cg
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/17/89)
New hunk types. Chris isn't the only one who wants to know! post replies to the net! * what additions has Lattice made ? * are they to be considered 'standard'? -Matt
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (05/17/89)
In article <0353.AA0353@ami-cg> cg@ami-cg.UUCP (Chris Gray) writes: >The AmigaDOS technical >reference manual describes hunk types 999 - 1011, 1013, 1014. Lattice will >generate 1016, which I would guess is an a4-relative offset. Is 1015 used >for anything? What about the new stuff for libraries? In HUNK_EXT's, I know >of types 0 - 3, 129 - 132. Lattice uses 134, presumeably again for a4-relative >stuff. Is 133 used? Could someone please send me a definition of all of the >new codes so that I can make my dumper/disassembler as general as possible? Here's what I've deciphered or heard about the Lattice hunk formats. Somewhere or another I have a version of Matt's "hunks" program which I modified to include these, and I also have some documentation from Lattice on the library format. If there's a big demand for details, I could probably be talked into uploading this. 1015 is DREL32, 1016 is DREL16, and 1017 is DREL8, all for relative offsets. These basically look like 1004-1006 (RELOC32 through RELOC8). In libraries, Lattice uses 1018 for HUNK_LIB, and 1019 for HUNK_INDEX, 1018 holds the object modules in the library. The INDEX comes directly after the LIB hunk, so a library looks like HUNK_LIB length HUNK_CODE ...(and stuff) HUNK_... and so on HUNK_INDEX length index stuff HUNK_whatever. If you don't need to parse the index, you can just treat the insides of a HUNK_LIB as normal object modules (there's nothing special in there, I believe), and just skip over any HUNK_INDEX hunks. The HUNK_LIB does not contain any HUNK_UNIT or HUNK_NAME hunks, and the HUNK_EXT hunks do not contain any ext_def types--all this information is put into the HUNK_INDEX. EXT_REF8 isn't supported, and EXT_ABS is treated a bit oddly. A library can contain more than one LIB/INDEX pair, and hybrid libraries *are* allowed. The INDEX structure is pretty involved, so I'm not going to try to describe it here--but I could be talked into uploading the description from Lattice. *Special note* This means that it is possible to concatenate new style Lattice libraries, or even concatenate new style libraries with old style libraries. (I had said before that this wouldn't work, but according to the Lattice specs I was clearly wrong.) Type 134 is ext_dref16 (I think Lattice calls it DEXT16). I assume that 133 is dref32, and 135 dref8, but I'm not sure I ever verified that. That's all the new ones I know about, and I don't know for sure that 133 and 135 exist, and I don't know if these are "official" as far as C-A is concerned. Hope this is helpful. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
toebes@sas.UUCP (John Toebes) (05/25/89)
In article <8905162220.AA21138@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > New hunk types. > > Chris isn't the only one who wants to know! post replies to the net! > > * what additions has Lattice made ? > * are they to be considered 'standard'? I will get together the document on the new types and see about posting it. It is however quite long so perhaps it might be better sent to comp.amiga.sources. To quickly summarize the extensions: a. 3 new hunk types to support data relative references. 1015 - DREL32 1016 - DREL16 1017 - DREL8 b. 3 new reference types to sypport data relative references. 133 - DEXT32 134 - DEXT16 135 - DEXT8 c. New hunk names to control merging of data NTRYHUNK - for the overlay manager to make it first __MERGED - The special data relative hunk _NOMERGE - A hunk not to be merged with anything else d. New naming conventions to support coalescing of constructor/ destructor functions for languages like C++ and Modula-2 A table of pointers to functions is built. I don't have the naming conventions on hand. e. Extensions to support library indexing: 1018 - HUNK_LIB 1019 - HUNK_INDEX Designed to allow indexing of the libraries while at the same time retaining the ability to construct libraries the old way by just concatenating the object modules together. All of the object file format extensions were reviewed and approved by Commodore before they were implemented - in particular the library indexing went through some careful scruitinizing. It has been acknowledged that these extensions are indeed part of the standard object file format. One additional *CONVENTION* that BLINK established is that HUNK_DEBUG must have one longword at the start of the hunk that is updated by BLINK to indicate the offset of the coalesced hunk that it is associated with. If you are generating one, it is best just to store a 0 as the first longword. Additionally, Lattice has defined a debug file format. The information can be obtained by contacting Lattice directly. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/