Hunks

[Hedeon]

Originally Posted by phx

I remember there is a PPC project (by Hedeon?), which has a special memory region indicated by a new MEM-flag. So it may be useful, as long as you have the right tool to create such object files.

I used it to flag the PPC hunks with MEM attributes $2005 which is used by Elbox to define memory located in PCI space (in their case VGA memory, in my case the memory on a PPC PCI card). So bit 31 and 30 were set of the hunk length in the hunk header followed by a ULONG with the value $2005. IIRC.

As the PPC on the PCI bus can only access memory located in PCI space I wanted to make sure that those hunks were loaded into memory residing in PCI space.

This of course only worked for stuff compiled with the extra stuff in the hunk header (thanks phx for this in vlink. I am talking about 2016 now I think). Original WarpOS stuff needed a patch of the hunk header.

Later I just patched LoadSeg() and used InternalLoadSeg() and some other stuff to recognize PPC programs and load them into PPC memory directly.

[Olaf Barthel]

Originally Posted by paraj

In the header, yes, but not subsequent hunks according to my testing (2.0/3.0/3.1). Do you have an example of an executable where this works? This is just for my curiosity as I can't see any use of this feature

The binary file loader only ever allocates the segments once when the header is processed. This is when it needs to know how much memory to allocate per segment and the associated allocation flags passed to the AllocMem function (or whatever the equivalent callback function for InternalLoadSeg does). Note that the memory allocation function must return a pointer to memory whose contents can be modified. Returning a ROM address is not an option. Do not second-guess what the loader might try.

When this segment list setup has been taken care of, the HUNK_CODE/HUNK_DATA/HUNK_BSS type hunks will be processed in the order in which they are found in the file. For each such hunk type the loader expects the hunk size to be either smaller than what was allocated or exactly the same.

The size of the hunk is really just the number of 32 bit words, no flags are expected or even supported. It is too late to change anything now anyway. The loader will not free and reallocate any part of the segment list.

If the size of the hunk is smaller than what was asked for at allocation time, then the memory which was not initialized yet will be filled with 0.

This is where things can go really wrong if the load file indicates that the size of the HUNK_CODE/HUNK_DATA/HUNK_BSS type hunk is larger than what was allocated. The loader does not expect this and may end up trashing memory.

[phx]

Originally Posted by paraj

In the header, yes, but not subsequent hunks according to my testing (2.0/3.0/3.1).

Originally Posted by Olaf Barthel

The size of the hunk is really just the number of 32 bit words, no flags are expected or even supported. It is too late to change anything now anyway.

Maybe it's just me, but I think you both agree in confirming the same fact: There are no memory flags in the size-longword, following the HUNK_CODE/DATA/BSS id in executable files.

Only with object files the memory flags are passed in this location. Simply because object files have no other place to pass them.

Some linkers in the past may have been too lazy to remove the flags there, when writing an executable. Which is usually not a problem (at least with either the CHIP or the FAST flag only), because the upper two bits disappear when multiplying by four, to determine the size in bytes.

More interesting (to me) is how the extended memory attributes word is passed in object files, when both bits are set, as I never found anything about it. I assumed that the extra word is passed directly behind the size-word in object files, i.e.:

dc.l HUNK_CODE,HUNKF_CHIP|HUNKF_FAST|size,memattr