On 07.02.2008 17:55, ron minnich wrote:
Lar does not currently process bss quite right.
I kind of blame ELF, but see what you think.
Here is filo. These are program headers used in Execution (the 'E' in ELF): LOAD 0x0000c0 0x00100000 0x00100000 0x11430 0x36890 RWE 0x20 LOAD 0x011500 0x001368a0 0x001368a0 0x00048 0x00048 RW 0x20
Note the LOAD sections. Here is more of FILO. These are section headers used in Linking (the 'L' in ELF') [ 2] .text PROGBITS 00100080 000140 00e667 00 WAX 0 0 16 [ 3] .rodata PROGBITS 0010e6e8 00e7a8 002b73 00 A 0 0 4 [ 4] .eh_frame PROGBITS 0011125c 01131c 000070 00 A 0 0 4 [ 5] .data PROGBITS 001112e0 0113a0 000150 00 WA 0 0 32 [ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0 32 [ 7] .initctx PROGBITS 001368a0 011500 000048 00 WA 0 0 32
OK, where did the LOAD sections come from? The first is a combination of .text, .rodata, .eh_frame, and .data. .initctx is the second one.
What's the FILO problem? Well: ide_probe: ide_probe drive #0 ide_probe: ctrl 1188128 base f9e8
base f9e8 is the IO base for the controller. f9eh? WHAT IS THAT? Well, it is a chunk of memory that is *supposed* to be zero!
it's garbage. it's in the .bss area and lar does not initialize it or anything. Why? Well: [ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0 32
Note that there is NO program header (LOAD above) for this area of memory! There is only this program header!
So the elf processor in LAR (which I grabbed from v2) is not processing that section. I don't think it should have to: it's a section header, not a program header, but this is an esoteric argument.
So I need to modify LAR to create another payload segment for .bss, which is just a zero-filled thing.
Nice analysis.
I will just look for a section header named .bss and use that. Now, this will be a zero-filled LAR entry but once compressed it will be nothing -- zero's compress nicely. But should we have a LAR type BSS for this type of usage? I am wondering. The BSS type would have a base address and size, and would be taken to mean "Zero this piece of ram".
I'd go with your suggestion to use a compressed zero-filled LAR entry compressed with LZMA. It may not be perfectly efficient, but it is surely good enough when the alternative is additional LAR complexity in the ROM. LZMA compressed size table for zeros: size compressed 1 19 256 20 65536 90 1048576 231
We successfully sidestepped the "special LAR member for fillup", why not do the same with BSS? The fact that we can sidestep all those issues without changing the LAR header nor the LAR parser in ROM is a testimony to the thoughtful design that went into LAR.
Semi-OT: The LZMA utility we use will create zero length archives if it gets zero length input. That may be fatal if we ever add zero length LZMA comprssed files to the LAR. Maybe adding that case to a test suite will ensure the code never explodes.
Regards, Carl-Daniel