What is the correct interpretation of hunks with type 0x3f7?
I'm in the process of resurrecting the old DICE C compiler I first learned C on. I'm trying to use it with NDK3.2R4, but it seems to be having problems with the amiga.lib and small.lib that is part of this NDK - it reports "Fatal Unknown hunk type 0x000003f7 offset 0xc6f8" (this is on small.lib).
On checking the new AmigaDOS RKRM, hunk type 0x3f7 is mentioned under HUNK_RELOC32SHORT, which was introduced in AmigaOS V36, so it's perhaps not surprising that DICE does not support it. It also says that HUNK_RELOC32SHORT is actually 0x3fc but that V36-V38 "do not understand the hunk type 0x3fc properly and use instead 0x3f7". I read this to mean that 0x3fc and 0x3f7 are *both* HUNK_RELOC32SHORT.
I attempted to adapt the DICE source code to support HUNK_RELOC32SHORT. However it seems that this hunk in small.lib doesn't fit the specification for HUNK_RELOC32SHORT documented in the AmigaDOS RKRM.
Here's a hex dump of the relevant part of the file:
0000c6f0 4e 75 4e 71 00 00 03 f7 00 00 00 01 00 00 00 01 |NuNq............|
0000c700 00 00 00 12 00 00 00 00 00 00 03 ef 01 00 00 02 |................|
(Note that due to a bug in this particular DICE tool, it's reporting the offset as of the end of the hunk type, so the hunk is actually starting 4 bytes earlier at 0xc6f4.)
According to the RKRM, after the hunk type longword, all the following fields are 16 bits wide. Other than the word size, HUNK_RELOC32SHORT is handled the same as HUNK_RELOC32. But when I adapt DICE to parse it as 16-bit words, it fails to parse. But if I parse it as 32-bit longwords - just like HUNK_RELOC32 - it makes sense: first longword is 1, meaning there is 1 relocation entry in the table; next longword is also 1, referring to the hunk it is relocation; next longword is 0x12, which is the offset into the hunk content to apply the relocation. There's a final longword of zero which I'm not sure about, then we can see the next hunk of type 0x3ef (HUNK_EXT).
So what is the correct interpretation of this hunk? Is it RELOC32 or RELOC32SHORT or something else?
Thanks for any clues you can give me!
Richard.
All the amiga.lib/small.lib versions in the NDK 3.2 releases 1-4 were built with the same compiler (SAS/C 6.59) settings as the operating system components would use, with regard to optimization and code generation. We later learned that amiga.lib/small.lib should have always been built using the compiler settings for which the output most closely matched what the 1985 Green Hills 'C' compiler would have generated. Hence, no 16 bit relocations and no use of hunk types which did not exist prior to 1989, such as 0x3f7 which stands for HUNK_RELOC32SHORT.
It would have been nice to know that this behaviour is "sort of" part of the specification, but it is really just a historic accident: Commodore built amiga.lib/small.lib, debug.lib and ddebug.lib on a Sun 3 workstation using the original 1985 Green Hills 'C' compiler and the matching vintage Metacomco macro assembler during the years 1987-1994.
The NDK 3.2R5 has been in the making for a very long time now, owing to effort spent on improving the AmigaDOS Autodocs (which have taken on an epic quality and will be performed on stage come May next year at Glyndebourne if the funding for the pending orchestration work comes through). New amiga.lib/small.lib and reaction.lib versions will be included, which are built using the same code generation settings, so that they match the properties of the original amiga.lib.
There are, however, drawbacks in linking against amiga.lib/small.lib and also reaction.lib in this form. All the 'C' support functions provided only accept parameters on the stack and there are not always equivalent function entries which make use of registerized parameters. This is a minor annoyance for sure, but with reaction.lib the lack of registerized parameter support might make a difference, and not for the better.
With regard to HUNK_RELOC32SHORT: Support for HUNK_RELRELOC32 type hunks in loadable binary files was added in Kickstart 3.0 with very little documentation to accompany this feature. As implemented, it uses unsigned 16-bit relocation offsets which renders this feature less useful than elementary PC-relative addressing. As the hunk type name suggests, it should be using 32-bit relocation offsets, though. Which useful purpose this feature might serve is hard to tell. Reimplementing it to use 32-bit relocation offsets makes little sense either without changing the hunk type value.
It is possible that you are seeing not HUNK_RELOC32SHORT in the amiga.lib, but HUNK_DREL32. Due to an oversight, HUNK_DREL32 ended up sharing the same value 1015 as HUNK_RELOC32SHORT when implemented in dos.library.
Thank you for the comprehensive answer - and yes, I see now separate documentation in the RKRM for HUNK_DREL32 with the same 0x3f7 type word. With this information I was able to understand the amiga.lib/small.lib format.
Richard.
Online Status
Another way of describing it, perhaps if the above isn't clear:
amiga.lib and small.lib, in NDK3.2R4, do not appear to comply with the hunk format described in the AmigaDOS RKRM, starting from the hunk in those files with type 0x3f7. Which statement is true?
1. amiga.lib/small.lib are malformed
2. the AmigaDOS RKRM is incorrect
3. I'm wrong