Mail Archives: djgpp/2001/06/28/11:15:03
On Tue, 26 Jun 2001 16:12:23 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> 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.
- Raw text -