COFF Specification and Loading

[Kenny]

Using the specification at http://www.delorie.com/djgpp/doc/coff/ I have tried to write a COFF loader for loading libraries and whatnot into my OS. I have built a test library in C and compiled it into a .o file and compared it to the specification.

So far, everything in the file is fine except for the uninitialised static data.

Initialised static data is in the .data section and the relocation information for the symbols all ties together, however, the symbols for uninitialised static data do not refer to a section and do not have a variable size specified, instead suggesting they are defined externally. I was expecting them to refer to the .bss section, and for the bss section to have a memory size that needed to be allocated.

Can someone please alleviate my confusion, or point me toward a better COFF specification?

Thanks

[Kenny]

My apologies, I was not entirely accurate in my question.

Global static variables are correctly mapping to the .bss section of the file, but global variables that are not defined as static are being defined as external with no apparent size information.

The Microsoft PE/COFF specification from Bone Fide implies that the Value field in External Symbols represents type, but the value I have ( 0x10 for a global int variable ) does not seem to map to any type table. If this is case, do I need to parse the Symbol table and allocate memory for these variables one-at-a-time? Why wouldn't these be covered by the .bss section?

Any insight is appreciated.

[gedd]

I think you should try this link for more details on PE/COFF format
http://www.microsoft.com/whdc/system/pl ... ECOFF.mspx

But before you should reconsider the use of this format. It is pretty complex.

[natp]

Global static variables are correctly mapping to the .bss section of the file, but global variables that are not defined as static are being defined as external with no apparent size information.

This is done to support "common" global variables. I don't know how you would allocate memory for them, but you can avoid the problem by using the GNU linker to move the common variables into the BSS: "ld -r -d -o newfile.o oldfile.o"

The Microsoft PE/COFF specification...

You previously mentioned DJGPP. Even though DJGPP COFF and PE COFF object files are indistinguishable, they are not the same. The relocations work differently. Symbol table might also be different, but I'm not sure.

Other people can tell you how to do DLLs, if you want to use those instead of .o files.

[Kenny]

Thanks for the point about moving them into the BSS, that might be exactly what I need.

I am using DJGPP COFF. I only had a look at the Microsoft PE/COFF spec just to see if it would give me any pointers (no pun intended) as to how to allocate these variables, but it didn't help.

I shall see if shifting the values into the BSS helps (it should), otherwise I'll have to find a book on the subject.