loftus@wpllabs.UUCP (William Loftus) (02/25/91)
Does anyone have the specs for the Amiga's object file format? Thanks -- William Loftus (215) 668 3661 WPL Laboratories, Inc. UUCP: loftus@wpllabs.UUCP P.O. Box 111 ARPA: loftus!wpllabs@prc.unisys.com 216 Wynne Lane Penn Valley, PA 19072 Ada and Unix Software Consultants
ben@epmooch.UUCP (Rev. Ben A. Mesander) (02/26/91)
>In article <loftus.3785@wpllabs.UUCP> loftus@wpllabs.UUCP (William Loftus) writes: > >Does anyone have the specs for the Amiga's object file format? The documentation for the Amiga object file format, as well as the documentation for the dos.library are in the book "The AmigaDOS Manual". I have the 2nd edition; it's not a wonderful book, but the information is in there, and you can puzzle out what it all means. -- ben@epmooch.UUCP ben%servalan.UUCP@uokmax.ecn.uoknor.edu {chinet,uokmax}!servalan!epmooch!ben (Ben Mesander) War in gulf: newpath 288 396 216 0 360 arc 288 612 moveto 288 180 lineto 288 396 moveto 136 244 lineto 288 396 moveto 440 244 lineto 36 setlinewidth stroke showpage
bcphyagi@csunb.csun.edu (Stephen Walton) (02/28/91)
In article <ben.5088@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >In article <loftus.3785@wpllabs.UUCP> loftus@wpllabs.UUCP (William Loftus) >writes: >> >>Does anyone have the specs for the Amiga's object file format? > >The documentation for the Amiga object file format, as well as the >documentation for the dos.library are in the book "The AmigaDOS Manual". This information is badly out of date. In particular, it does not contain SAS's extensions for library indexes and debugging information, which are used extensively by SAS's and now, I think, others' tools. You can probably get the spec from either CATS or from SAS directly. -- Stephen R. Walton, Dept. of Physics and Astronomy, Cal State Northridge bcphyagi@csunb.csun.edu until my Suns come back up
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/01/91)
In article <1991Feb27.211703.12787@csun.edu> bcphyagi@csunb.csun.edu (Stephen Walton) writes: >In article <ben.5088@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) >writes: >>In article <loftus.3785@wpllabs.UUCP> loftus@wpllabs.UUCP (William Loftus) >>writes: >>> >>>Does anyone have the specs for the Amiga's object file format? >> >>The documentation for the Amiga object file format, as well as the >>documentation for the dos.library are in the book "The AmigaDOS Manual". > >This information is badly out of date. In particular, it does not contain >SAS's extensions for library indexes and debugging information, which >are used extensively by SAS's and now, I think, others' tools. You can >probably get the spec from either CATS or from SAS directly. >-- >Stephen R. Walton, Dept. of Physics and Astronomy, Cal State Northridge >bcphyagi@csunb.csun.edu until my Suns come back up It isn't out of date. The only real extension to the original documentation is a new small-data hunk and small-data external symbol id. SAS's library indexes are cute but I'm not sure how official they are, and the DEBUGing hunks are SAS/C specific, *NOT* commodore-amiga standard (there is no commodore-amiga standard). Frankly, the library indexes can almost be ignored. It is just as fast to scan the entire library then random access through the directory because you generally hit all the sectors anyway, and random access is less efficient. DLink is as fast or faster than BLink and just uses straight JOIN'd object modules. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
markv@kuhub.cc.ukans.edu (03/12/91)
In article <ben.5088@epmooch.UUCP>, ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>In article <loftus.3785@wpllabs.UUCP> loftus@wpllabs.UUCP (William Loftus) writes: >>Does anyone have the specs for the Amiga's object file format? > > The documentation for the Amiga object file format, as well as the > documentation for the dos.library are in the book "The AmigaDOS Manual". > I have the 2nd edition; it's not a wonderful book, but the information > is in there, and you can puzzle out what it all means. But this doesn't include the (official/registered?) Lattice/SAS extensions to the object file format. Does anyone know where to find notes on these, things like flagging near/far accesses, CodeProbe symbol format, etc. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ahh@glyph.kingston.ny.us (Andy Heffernan) (03/13/91)
In article <29013.27db5fd9@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >In article <ben.5088@epmooch.UUCP>, ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>>In article <loftus.3785@wpllabs.UUCP> loftus@wpllabs.UUCP (William Loftus) writes: > >>>Does anyone have the specs for the Amiga's object file format? >> >> The documentation for the Amiga object file format, as well as the >> documentation for the dos.library are in the book "The AmigaDOS Manual". >> I have the 2nd edition; it's not a wonderful book, but the information >> is in there, and you can puzzle out what it all means. > >But this doesn't include the (official/registered?) Lattice/SAS >extensions to the object file format. Does anyone know where to find >notes on these, things like flagging near/far accesses, CodeProbe >symbol format, etc. > +----- From the archives: Path: glyph!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!riley From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley) Newsgroups: comp.sys.amiga.tech Subject: Re: New AmigaDOS hunk types Keywords: hunk Lattice disassembler Message-ID: <7968@batcomputer.tn.cornell.edu> Date: 17 May 89 16:34:01 GMT References: <0353.AA0353@ami-cg> Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley) Distribution: na Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 56 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. Path: glyph!uunet!lll-winken!xanth!ukma!gatech!mcnc!rti!sas!toebes From: toebes@sas.UUCP (John Toebes) Newsgroups: comp.sys.amiga.tech Subject: Re: New AmigaDOS hunk types Message-ID: <1054@sas.UUCP> Date: 25 May 89 12:45:10 GMT References: <8905162220.AA21138@postgres.Berkeley.EDU> Reply-To: toebes@sas.UUCP (John Toebes) Organization: SAS Institute Inc, Cary NC Lines: 54 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-----*/ /*------------------------------------------------------------------------*/ +----- end of archives -- ------------------------------------------------------------------------- Andy Heffernan $BJ8;z(J uunet!glyph!ahh