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.
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".
Comments?
ron