First, the OCF format is great - I like it much better than the ELF, had to study both in the last 5 weeks.
Second, While we can preserve the overall OCF file structure, some things in it will still have to change. The reason is that OCF holds the image for the metadata, and that hold pointers, and they grow from 4 to 8 bytes.
adimetrius wrote:
So my idea was that the processor code (a new one for amd64) could indicate that OCF holds 64-bit data. The new code would stop old tools from looking into the file and misinterpreting it.
It is better to set high bit of CPU field to indicate 64 bit module or something similar. 64 bit modules can be also used by aarch64, PowerPC, MIPS etc.. Various module tools (loaders, linkers, decoders) can work without knowledge of instruction set.
adimetrius wrote:
Now, to the UseBlk. Currently, Herschel generates PIC - it needs no relocations when it's base is changed (when it's loaded at varying base addresses). It also does not need any binding fixups (to bind/link to imported symbols).
Addresses of imported CP procedures and external host library functions are collected in one place - the proxy table. References to the proxy table are hard-coded into the generated code.
Code fixups (fixups with type "relative") may be still needed for static linking to merge same OCF segments of multiple modules into one ELF segment. Proxy tables may be merged into one ELF GOT/GOT-PLT table with different protection. Hard-coded code offsets into proxy table may require a lot of ELF segments or mixing code with data.
adimetrius wrote:
All this to say, the UseBlk's link list holds only one value.
This is how a UseBlk procedure entry was defined in OCF:
UProc = 4X name fprint link.
link = {fixupadr offset} 0X.
Now, in OCF/64, the fixupaddr is the address in the proxy table, and the offset is zero. (Also, fingerprinting is no yet implemented, so the fingerprints are written out as zeroes).
This violates current OCF fixup format. Fixup link address have specific format. If it positive, it it offset to code segment (0 < link < codeSize). If it negative, its negation is offset to meta segment (0 < -link < metaSize) and then to desc segment (metaSize <= -link < metaSize + descSize). Proxy segment can be added to this fix fixup link format, for example (metaSize + descSize <= -link < metaSize + descSize + proxySize). Zero proxy record will be not needed.
adimetrius wrote:
Does this answer your question?
Thanks for explaining.