XBR1YD22@DDATHD21.BITNET (Ralf Bayer {Herz-Baerchi}) (05/16/86)
I'd like to know the meaning of the information that is stored at the
beginning of a TOS executable file.
address data meaning
0000 60 1A BRA $001C ;branch over fields
0002 00 00 7E EC length of file?
0006 00 00 00 00 ?
000A 00 02 25 04 ?
000E 00 00 00 00 ?
0012 00 00 00 00 ?
0016 00 00 00 00 ?
001A 00 00 ?
001C ;begin of actual program
What do the several fields mean? Are they absolutely necessary or are
they just information for programs like debuggers and the like? Any
information greatly appreciated.
BTW, does anybody have a PD disassembler? Could someone mail it to me?
Thanx,
Ralf Bayer (The Care-Baer)
Computing Center @ the Technical University of Darmstadt, West Germany
Arpanet: xbr1yd22%ddathd21.BITNET@wiscvm.wisc.EDU (personal mail)
#d22%ddathd21.BITNET@wiscvm.wisc.EDU (mailing lists)
BITNET: xbr1yd22 @ ddathd21 (no NETDATA format, need RFC-header)
#d22 @ ddathd21 ( NETDATA format, beware of the
Number sign, it's part of the USERID)
-----------------------------------------------------------------------
> REAL programmers use FORTRAN <
-----------------------------------------------------------------------turner@imagen.UUCP (05/17/86)
> I'd like to know the meaning of the information that is stored at the > beginning of a TOS executable file. ask and thou shalt recieve: Date: Sun, 22 Dec 85 22:14:31 est From: decwrl!decvax!cwruecmp!bammi (Jwahar R. Bammi) To: decvax!decwrl!imagen!turner Subject: Format of '.prg' files Cc: decwrl!bammi I extracted the following info. from documents that came with the development system. I have only found the .prg (output of relmod) format, and not the .o format. The input of relmod is the standard cp/m-68K relocatable files, so I guess the .o format is the same as for cp/m-68K. I am not at all familiar with cp/m-68K, and i could not find anyting in the documents I have about the format of .o files. Maybe you are familiar with cp/m-68k or have access to the relevant cp/m-68k documents. Looking forward to your PD diss assmebler. The format for a .prg file is as Follows (word = 16 bits). Output of relmod - 16 bit relocatable objects are not supported by Gem Dos. 14 Word Header Text Segment Image Data Segment Image Symbol Table (Optional) Relocation Info (Optional) Header Format: Byte Size(words) Contents 0 1 Contains 601A H Denoting Contiguous text, data and block storage segments 2 2 Size of Text Segment - Bytes 6 2 Size of Data Segment - Bytes 10 2 Size of Block Storage Segment - Bytes 14 2 Size of Symbol Table - Bytes 18 2 Reserved - Always Zero 22 2 Reserved - Always Zero (This is supposed to contain the Begining of the Text Segment and execution, but execution always begins at the top of the Text segement, hence 0) 26 1 If Zero then Relocation info IS present, No relocation info otherwise. Always Zero for Gem Dos. Symbol Table Format: Each entry is 7 words. Byte Size(words) Contents 0 4 Name - zero padded to 8 characters 8 1 Type 10 2 Value Type Value defined 8000 H equated 4000 H global 2000 H equated register 1000 H external reference 800 H data based reloc. 400 H text based reloc. 200 H bss based reloc. 100 H where: reloc. == relocatable A symbol with multiple characteristics has the bits OR'ed in the type field. The value field is the value of the symbol (address, register number, value of an expression or some other value). When the value field is non-zero AND the type field contains an External Symbol, the linker interprets the value to be a common region in which the size of the region is the value in the value field. Multiple such entries may be present and the size of the common that the linker ultimately decides on, is the greatest of the values, of the same name. The nm68 utility provided with the development system can be used to dump the symbol table. Relocation Information: If the last word in the header is Zero the relocation info is present in the following format: (following symbol table if present) Byte Size (BYTES) Contents 0 4 Offset from the beginning of the Text Segment of the first longword needing relocation. 4 1 Relocation offset byte 5 1 " " " ..... xx 1 A byte containing Zero terminates Relocation offset byte - Gives the offset to the Next longword in the Text Segment to relocate (offset from the First Offset ) and so on. When an offset of Zero is encountered the relocation info is terminated. The bytes of Relocation offset give succeeding offsets. (so the smallest legal value is 4 (size of long word)). If a succeeding offset is greater than 254, then a byte containg One (1) will be encountered, signifying add 254 to the previous total. I hope that I explained the above clearly. I guess an example is appropriate to say what i mean. Suppose that the first longword to be relocated is at offset 128 from the begining of the text segment. The next one is at offset 132 from the begining. The next is at offset 390 from the begining of the text segment (ie. 258 bytes from the second longword to be relocated ), Then the relocation info looks like byte Size(BYTES) Contents 0 4 128 4 1 4 5 1 1 (add 254) 6 1 4 (128 + 4 + 254 + 4 = 390) and so on. I hope the above info help. Seasons Greetings Jwahar R. Bammi Usenet: .....!decvax!cwruecmp!bammi CSnet: bammi@case Arpa: bammi%case@csnet-relay CompuServe: 71515,155 -- ---- "If only you could see what I've seen with your eyes" -Blade Runner Name: James M. Turner (not the James M. Turner at Lisp Machine Inc.) Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner CompuServe: 76327,1575 GEnie : D-ARCANGEL