From: "John S. Fine" Newsgroups: comp.os.msdos.djgpp Subject: Re: RELOC_XXXXX Date: Fri, 23 Apr 1999 10:45:05 -0400 Lines: 26 Message-ID: <37208771.7F75@erols.com> References: <01be8d34$6cc63f20$LocalHost AT thendren> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: y0lVlhqGSqIY9EkLnAoh/D4RAsriYa+oFxt1axz8dtw= X-Complaints-To: abuse AT rcn DOT com NNTP-Posting-Date: 23 Apr 1999 14:46:42 GMT X-Mailer: Mozilla 3.01 (Win95; U) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Christopher Nelson wrote: > okay. thanks again. the one last question I had, and maybe this answered > it, if you have an uninitialized global variable, it list's it's section as > 0 in the COFF file. obviously 0 does not exist, since sections start at 1. > am i supposed to allocate space for all the uninitialized variables myself? > or are they stuck somewhere that's not obvious. my guess would have been > bss, but that's not what happens... It is a form of named common. You do need to allocate space for it. The size of the required space was in some field that usually means something else. IIRC it was in the field that gives the offset within the segment. I think you are supposed to be able to declare an uninitialized global variable in more than one module. The linker matches them up so that only one copy is actually allocated. When I first added COFF support to my linker, this is the feature I completely misunderstood. The HTML document on COFF format doesn't seem to cover it at all. After I found the problem, I kludged in code to merge all these into the end of the BSS. That is probably not exactly what is intended, but it has worked well enough. -- http://www.erols.com/johnfine/ http://www.geocities.com/SiliconValley/Peaks/8600/