leemc@csri.toronto.edu (Matthew Lee) (05/26/90)
Hello Netland,
I'm *attempting* to port some code (not written by myself) from MSC 5.1 to
TC 2.0 . The code consists of several 'C' source files and one .asm file. When
I attempted to link the object code, compiled in large model, I get several
error messages of the form:
"Fixup overflow in module FOO.C at FOO_TEXT:XXXX, target = _VARIABLE"
Now, all of the "_VARIABLE"'s are global variables declared as PUBLIC in the
CODE segment of the assembler file. There are corresponding "extern VARIABLE"
declarations in the 'C' files.
Anybody have an idea how to fix this? After looking through a few manuals I am
none the wiser although I suspect that the tlink is looking for the "VARIABLE"'s
in the DATA segment, not the CODE segment.
Sorry if I haven't given enough details, I'm hoping this a problem somebody
has seen before and has a straightforward fix.
Any suggestions welcome. Thanks!
Matthew Lee
University of Toronto
leemc@csri.toronto.eduP88035@BARILVM.BITNET (Ephraim Vider) (05/31/90)
In article <1990May25.134431.25796@jarvis.csri.toronto.edu>, leemc@csri.toronto.edu (Matthew Lee) says: > >Hello Netland, > >I'm *attempting* to port some code (not written by myself) from MSC 5.1 to >TC 2.0 . The code consists of several 'C' source files and one .asm file. When >I attempted to link the object code, compiled in large model, I get several >error messages of the form: > > "Fixup overflow in module FOO.C at FOO_TEXT:XXXX, target = _VARIABLE" > >Now, all of the "_VARIABLE"'s are global variables declared as PUBLIC in the >CODE segment of the assembler file. There are corresponding "extern VARIABLE" >declarations in the 'C' files. > >Anybody have an idea how to fix this? After looking through a few manuals I am >none the wiser although I suspect that the tlink is looking for the s >"VARIABLE"' >in the DATA segment, not the CODE segment. > >Sorry if I haven't given enough details, I'm hoping this a problem somebody >has seen before and has a straightforward fix. > >Any suggestions welcome. Thanks! > Even in large model - Turbo C expects all static data to be in the default data segment named _DATA and all offsets to these variables are calculated from DGROUP. This apperantly causes problems when variables are in another segment. The way to fix this problem is to declare extern int far foo; in your C code. The far keyword tells the compiler that this variable is not in the default data segment. This solution worked for me in a similar situation. Ephraim
leemc@cs.toronto.edu (Matthew Lee) (06/01/90)
In article <90151.102706P88035@BARILVM.BITNET> P88035@BARILVM.BITNET (Ephraim Vider) writes: >In article <1990May25.134431.25796@jarvis.csri.toronto.edu>, >I wrote: >> >>Hello Netland, >> >>I'm *attempting* to port some code (not written by myself) from MSC 5.1 to >>TC 2.0 . The code consists of several 'C' source files and one .asm file. When >>I attempted to link the object code, compiled in large model, I get several >>error messages of the form: >> >> "Fixup overflow in module FOO.C at FOO_TEXT:XXXX, target = _VARIABLE" >> >>Now, all of the "_VARIABLE"'s are global variables declared as PUBLIC in the >>CODE segment of the assembler file. There are corresponding "extern VARIABLE" >>declarations in the 'C' files. >> >>Anybody have an idea how to fix this? After looking through a few manuals I am >>none the wiser although I suspect that the tlink is looking for the s >>"VARIABLE"' >>in the DATA segment, not the CODE segment. >> >>Sorry if I haven't given enough details, I'm hoping this a problem somebody >>has seen before and has a straightforward fix. >> >>Any suggestions welcome. Thanks! >> > > Even in large model - Turbo C expects all static data to be in the >default data segment named _DATA and all offsets to these variables >are calculated from DGROUP. This apperantly causes problems when >variables are in another segment. > >The way to fix this problem is to declare > > extern int far foo; > >in your C code. > The far keyword tells the compiler that this variable >is not in the default data segment. > This solution worked for me in a similar situation. > > Ephraim Yes, you are right, that's the way its done. I eventually puzzled it out on my own after several perusals of various manuals, snooping through generated asm code etc. Good thing I didn't see your posting a week ago or I wouldn't know all I do now about segmentation, memory models and all that other fun stuff. Thanks for your response. Matt leemc@csri.toronto.edu