On 25/02/12 12:53, David Given wrote: [...] > I'm now thinking that the sanest way to go here is (a) hack Watcom to > support ELKS executables directly; (b) write a tool to disassemble the > OMF output and convert it to as86-compatible format; (c) give up and go > to the pub... Actually, I forgot option (d): change ELKS. It occurs to me that the kernel doesn't actually need to know the BSS size. All it's doing is allocating a data segment the size of the chmem field, loading the preinit data from the file, and zero-initialising the rest. So all it needs is the preinit data size, which we have, and the chmem size, which we have. So if we're willing to decree that the kernel ignores the BSS size field, we're good to go... ...in fact, looking at fs/exec.c, I reckon that it should work as is. The only place the BSS size field is used in an old-style executable is during the call to memset, where 0 is safe. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Never attribute to malice what can be adequately explained by │ stupidity." --- Nick Diamos (Hanlon's Razor)
Attachment:
signature.asc
Description: OpenPGP digital signature
