It appears the Program Segment Flags is the latest point at which a chunk of a program could be marked as compressed (independent of other chunks)
ELF Header gives offset/length of Program Segment header PHDR -Program Segment header[n] entries have struct member u32 p_flags
p_flags has 0x0000_0001 exec 0x0000_0002 write 0x0000_0004 read 0xf000000 left for processor specific
out of 32 bits, that leaves 25 bits for compression type.
Programs are divided into Segments depending on the permissions (.text rx, .data rw), which might separate 1 compressor stream into 2 streams, but, if we're not setting page protection bits in MMU, we could concatenate 2 Segments/ into 1 compressor stream if there's some compressor gains.
They are also divided into Segments based on vma/lma, but those could be contiguous for a firmware application.
the existing semantics are, if size in memory (p_memsz) is specified bigger than size in file (p_filesz), pad with zeros.
What i'm pointing out is there is a field which tells the size in-file... this would just change to being the compressed size.
In order for zero-padding to be viable then, the compression algo needs to return the uncompressed size from the data blob. Failing that, p_memsz becomes the uncompressed size, and you loose the zero-padding feature.
It would be "neat" for gnu binutils to support this directly. Failing that, we can do what Linux does, export Segments to binary file, run thru gzip, feed back to ld. I'll have to see if LD lets us fiddle with the p_flags, or do we start with a "mkelfimage" that just tweaks them in the output of ld.
On Mon, 2008-04-14 at 14:27 -0700, ron minnich wrote:
yeah, but we're a BIOS, what do we care. :-)
Let me ask the question differently. The implementation is easy, I will grant that. But where in the segment headers are the flags that indicate the type of compression used?
ron