From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: Peculiar behavior of program. Organization: Low Charisma Anonymous Message-ID: <3b3b4662.211401101@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 78 Date: Thu, 28 Jun 2001 15:11:52 GMT NNTP-Posting-Host: 207.176.153.4 X-Complaints-To: news AT primus DOT ca X-Trace: news1.tor.primus.ca 993741174 207.176.153.4 (Thu, 28 Jun 2001 11:12:54 EDT) NNTP-Posting-Date: Thu, 28 Jun 2001 11:12:54 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Tue, 26 Jun 2001 16:12:23 +0300 (IDT), Eli Zaretskii sat on a tribble, which squeaked: >> That suggests to make such a scheme be used when code is compiled with >> -g and not -fomit-frame-pointer. > >The problem is, -fomit-frame-pointer is a compiler switch, while the >setup of the runtime environment is done in the library. How will the >library startup code know that -fomit-frame-pointer was used or not? That's easy. What decides what file to use to link in the standard library? I don't see anyone having to link with -libc. So the tools are doing it automagically. Now imagine that the startup code is isolated into a separate module, say -lcrt, instead of included in libc. (Maybe this is already the case.) There are, in fact, *two* versions of libcrt.a, one for a certain debugging scenario, the other for general usage. The decision as to which one to link is made based on a flag passed from the compiling stage, possibly hidden inside one or more of the .o files. Doesn't look so impossible now, does it? >In any case, forcing the programmer to change compilation switches to >debug is a Bad Idea (tm): one more general-purpose register makes a >world of difference on x86, so you are essentially debugging a >different program. This is already done when one uses -fomit-frame-pointer simply to get a more extensive traceback. People do it all the time and the world hasn't stopped spinning on its axis. >In any case, the current setup is based on lots of experience and hard >work by many people, so you can safely assume that any reasonable >alternative was already examined and found to be worse. If that's the case, then it's time to examine the "unreasonable" alternatives. The best case often lurks in this oft-unexamined set, when "reasonable" is predicated on an assumption that wasn't thorouhgly checked out. Look under every rock, and sometimes (even though not always) you will get a pleasant surprise. >There are other DPMI hosts that support this feature. Such as? I've never heard of any. If they exist, they are so obscure nobody's using them anyway. >So identification is not so simple. If so, then why not modify CWSDPMI to exhibit a "signature" of sorts? You guys are supposed to be pretty wizardly hackers. Here I have at least one viable idea, while you stubbornly claim it's impossible. The idea is basically a take on the above: CWSDPMI can do something strange and different exactly once and the code can check for it. E.g., suppose there's a DPMI function to return free memory (is there?). CWSDPMI can have this return an obviously bogus value (e.g. a negative one) the first call, and DJGPP's startup code can check for this. User code won't notice CWSDPMI's "quirk" because when it starts running CWSDPMI has reverted to "normal" behavior. Of course, this would cause problems if CWSDPMI were used with a non-DJGPP app, but a) this probably doesn't occur and b) CWSDPMI can certainly check whether the app is DJGPP or not and behave accordingly (all DJGPP apps start with a common piece of stub code, IIRC, and you could always incorporate a signature in a newer version -- indeed, better to do the latter in case an older version is used with a newer CWSDPMI). The host and app thus "handshake" in a sense. Networking systems do it all the time to find out if each other support certain features without breaking backward compatibility (HTTP 1.1 seems to be an example). But the technique is clearly applicable anytime two automated systems with imprefect knowledge of each others' version and vendor but a certain required protocol have to work together. Server and browser, DPMI host and client, it's all the same on some level. -- Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980 "There's nobody getting rich writing software that I know of." -- 1980 "This antitrust thing will blow over." -- 1998 Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.