Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ames!haven!umd5!uvaarpa!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Structure of executables
Message-ID: <608@sas.UUCP>
Date: 22 Aug 88 05:36:21 GMT
References: <213@snll-arpagw.UUCP> <455@mace.cc.purdue.edu>
Reply-To: toebes@sas.UUCP (John Toebes)
Organization: SAS Institute Inc, Cary NC
Lines: 46

In article <455@mace.cc.purdue.edu> ain@mace.cc.purdue.edu.UUCP (Patrick White) writes:
>   BTW, Manx does not use the *object* module format that is explained in the
>manual.. don't know about Lattice.
>Pat White  (ain@s.cc.purdue.edu)
Lattice follows the standard as described in the Manual with the use of
three new hunk types and relocation types added by BLINK.  In addition,
Version 4.0 introduced an index hunk for creatring indexed libraries to
improve linking speed.  Full documentation on these extensions are available
through Lattice Tech Support.

All of these enhancements have been sent to Commodore for comment.  In
addition to the Lattice compiler, the CAPE assembler and ASM68k PD version
support all the BLINK enhancements.

Some important points
* ext_common and ext_res are not supported by BLINK.  To be fair, I have not
      been successful at making ALINK work with them.
* resident libraries do not do anything meaningful (trust me) and as such you
      will always see a 0 immediately after the HUNK_HEADER in a load module
      indicating that none are referenced by the module.
* Overlays require more than just the object file format information to 
      work.  The loader looks at magic values in the code to pass along
      information about the load file.
* A hunk may be terminated by more than one HUNK_END
* The loader only allows the following hunks:
    HUNK_HEADER
    HUNK_CODE   HUNK_DATA  HUNK_BSS
    HUNK_RELOC32
    HUNK_BREAK   HUNK_OVERLAY
    HUNK_SYMBOL  HUNK_DEBUG
    HUNK_END     HUNK_NAME
* if a HUNK_BSS is greater than 64K*4, only thle first 64K*4 bytes will
   be zeroed
* The hunk header and the size in the actual hunk doe not have to agree.
     Any excess in the hunk_header will be *UNINITIALIZED*.  This is used
     by BLINK to generate Supressed BSS as part of the Data section.
* HUNK_DEBUG sections have no inherent format.  However, Lattice and
   CAPE share the same format for line number tables:

There are many other hidden things in the object file format that I would
be more than willing to answer questions about.

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/