zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/07/89)
For a few programs I've written, I believe that I need to disable calls to chkstk (I'm calling microsoft C routines from an interrupt handler). I know about the /Gs option, but I'm concerned that the library routines might also call it. The best solution seems to be to write a null chkstk routine and link it in. This creates an error message about multiply defined symbols. Is there any way to get the linker to quietly use the first chkstk routine it finds? I've tried removing chkstk from the library with -chkstk, but this seems to remove some other needed routine or variable (STKHQQ). Are there any other ways to make sure that no routine calls chkstk? -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
john@stiatl.UUCP (John DeArmond) (01/07/89)
In article <5041@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >For a few programs I've written, I believe that I need to disable >calls to chkstk (I'm calling microsoft C routines from an interrupt >handler). I know about the /Gs option, but I'm concerned that the >library routines might also call it. > >The best solution seems to be to write a null chkstk routine and link >it in. This creates an error message about multiply defined symbols. >Is there any way to get the linker to quietly use the first chkstk >routine it finds? > Use the /NOE linker switch. The multiply defined error message the linker generates tells you to use this switch. RTFM .. er ... RTFcrt :-) >I've tried removing chkstk from the library with -chkstk, but this seems >to remove some other needed routine or variable (STKHQQ). > >Are there any other ways to make sure that no routine calls chkstk? > >-- > Jon Zeeff zeeff@b-tech.ann-arbor.mi.us > Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu > Ann Arbor, MI umix!b-tech!zeeff I'd recommend that you simply include an empty definition of _chkstk() for normal conditions and let the compiler include the call. I've found that this call is invaluable for debugging. Since it is called immediately before the function parameters are pushed, it is a very handy hook to attach debugging code to. The only time I've not let the compiler include the chkstk call is in EXTREMELY time critical routines. The only thing I wish is for Micro- Soft to include a similiar hook at the exit end of a function. john -- John De Armond, WD4OQC | "I can't drive 85!" Sales Technologies, Inc. Atlanta, GA | Sammy Hagar driving ...!gatech!stiatl!john | thru Atlanta!
kneller@cgl.ucsf.edu (Don Kneller) (01/07/89)
In article <5041@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >For a few programs I've written, I believe that I need to disable >calls to chkstk >The best solution seems to be to write a null chkstk routine and link >it in. This creates an error message about multiply defined symbols. >Is there any way to get the linker to quietly use the first chkstk >routine it finds? I believe you have to use the /NOE LINK switch. I would go into further details about why, but rather than disseminate false information (I don't recall the details) I refer you to your manual. - don ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
seg@smsdpg.uu.net (Scott Garfinkle) (01/08/89)
From article <5041@b-tech.ann-arbor.mi.us>, by zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff): > ... > Are there any other ways to make sure that no (MSC library) routine calls chkstk? By far the easies way is to buy the MSC library routines for $100 (as I recall), and recompile them with the -Gs option. It's worth the money just to have the source around, anyway. Scott E. Garfinkle SMS Data Products Group, Inc. uunet!smsdpg!seg
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/09/89)
>>For a few programs I've written, I believe that I need to disable >>calls to chkstk (I'm calling microsoft C routines from an interrupt >>The best solution seems to be to write a null chkstk routine and link >>it in. This creates an error message about multiply defined symbols. In article <2521@stiatl.UUCP> john@stiatl.UUCP (John DeArmond) writes: >Use the /NOE linker switch. The multiply defined error message the >linker generates tells you to use this switch. > >RTFM .. er ... RTFcrt :-) I have of course and /NOE doesn't do a bit of good. You still get a symbol defined more than once error. >>I've tried removing chkstk from the library with -chkstk, but this seems >>to remove some other needed routine or variable (STKHQQ). >I'd recommend that you simply include an empty definition of _chkstk() for >normal conditions and let the compiler include the call. I've found that this >call is invaluable for debugging. Since it is called immediately before the Thats what I'm trying to do. Do you have code that replaces _chkstk() and links without errors (MSC 5.0). -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
cramer@optilink.UUCP (Clayton Cramer) (01/10/89)
In article <5041@b-tech.ann-arbor.mi.us>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > For a few programs I've written, I believe that I need to disable > calls to chkstk (I'm calling microsoft C routines from an interrupt > handler). I know about the /Gs option, but I'm concerned that the > library routines might also call it. > > The best solution seems to be to write a null chkstk routine and link > it in. This creates an error message about multiply defined symbols. > Is there any way to get the linker to quietly use the first chkstk > routine it finds? > > I've tried removing chkstk from the library with -chkstk, but this seems > to remove some other needed routine or variable (STKHQQ). > > Are there any other ways to make sure that no routine calls chkstk? > > Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Writing your own null chkstk function doesn't work because the real chkstk function defines STKHQQ. Here's what I'm using to deal with all those library functions that call chkstk: TITLE CHKSTK.ASM: Replacement For CHKSTK PAGE 122,132 DOSSEG .MODEL LARGE .CODE SUBTTL __chkstk: Replacement chkstk public __chkstk public STKHQQ __chkstk proc far pop cx pop dx sub sp,ax push dx push cx retf __chkstk endp .DATA STKHQQ dw 0 end -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Disclaimer? You must be kidding! No company would hold opinions like mine!
cramer@optilink.UUCP (Clayton Cramer) (01/10/89)
In article <2521@stiatl.UUCP., john@stiatl.UUCP (John DeArmond) writes: . In article <5041@b-tech.ann-arbor.mi.us. zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: . .For a few programs I've written, I believe that I need to disable . .calls to chkstk (I'm calling microsoft C routines from an interrupt . .handler). I know about the /Gs option, but I'm concerned that the . .library routines might also call it. . . . .The best solution seems to be to write a null chkstk routine and link . .it in. This creates an error message about multiply defined symbols. . .Is there any way to get the linker to quietly use the first chkstk . .routine it finds? . . . . Use the /NOE linker switch. The multiply defined error message the . linker generates tells you to use this switch. . . RTFM .. er ... RTFcrt :-) Nope. /NOE isn't enough. . . .I've tried removing chkstk from the library with -chkstk, but this seems . .to remove some other needed routine or variable (STKHQQ). . . Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Because STKHQQ is defined in the real chkstk function, the null one needs to define STKHQQ also, or to resolve STKHQQ (even with /NOE), the real chkstk function will be linked as well, causing multiply-defined errors. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer Disclaimer? You must be kidding! No company would hold opinions like mine!