binfmt_som
I plunged further into the binfmt_* files today and have a fair idea what needs to be done next. One passage is slightly troubling me (page 6-126 of the runtime arch document),
``exec_dsize
This field specifies the size in bytes of the initialised data (does not have to be a multiple of 4k). The actual size of the data section in the file must be a multiple of 4k and can be padded with zeroes to make it a multiple of 4k.''
Does this mean in the case where exec_dsize is not a multiple of 4k, it MUST be padded with zeroes, or merely might be padded with zeroes? If the former, I don't need to zero them myself in the loader which would be nice.
Also, where does the bss section start? Is it immediately after the initialised data or at the next page boundary after it?
binfmt_som is going to be the cleanest binfmt in the kernel when I'm finished with it :-) [and then I'm going to clean up the others.]
Signature · 4 lines
Matthew Wilcox <[email protected]> "Windows and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture." - N Stephenson
In message <[email protected]>you write:
Quoted 9 lines
``exec_dsize
This field specifies the size in bytes of the initialised data (does not have to be a multiple of 4k). The actual size of the data section in the file must be a multiple of 4k and can be padded with zeroes to make it a multiple of 4k.''Does this mean in the case where
exec_dsizeis not a multiple of 4k, it MUST be padded with zeroes, or merely might be padded with zeroes? If the former, I don't need to zero them myself in the loader which would be nice.
Strictly reading the size in the file is guaranteed to be a multiple of 4k, but you can't necessarily depend on the pad being zero filled.
However, HP's linker always zero pads.
Quoted 2 lines
Also, where does the bss section start? Is it immediately after the initialised data or at the next page boundary after it?
It beings immediately after the initialized data. Note that HP's linker will decrease the size of the bss space by the amount of pad needed to fill out the data space's size to a multiple of 4k. This saves a little bit of memory in the resident image. Note this is only possible when the pad is zero filled.
To the best of my knowledge this behavior is not documented by HP anywhere. It is documented in bfd/som.c, as are many of SOM's wonderful quirks. Search for exec_header.
In case you're wondering why BFD has to know about this -- consider strip and objcopy. If you muck up an executable with those programs BFD has to be able to recreate the exec header based on the sections that will exist in the final output file.
jeff