From:	eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Bug 00314 -- div() still broken
Date:	25 Apr 2003 07:26:54 GMT
Organization:	Ericsson Erisoft AB, Sweden
Lines:	22
Message-ID:	<b8anvu$t6q$1@antares.lu.erisoft.se>
References:	<3e9c6920$0$21928$afc38c87@> <fA9pa.20115$1s1 DOT 299825 AT newsfeeds DOT bigpond DOT com> <3EA5477F DOT 2020901 AT cyberoptics DOT com> <SzSpa.21592$1s1 DOT 332473 AT newsfeeds DOT bigpond DOT com> <3ea85d95$0$12489$4c41069e AT reader1 DOT ash DOT ops DOT us DOT uu DOT net>
NNTP-Posting-Host:	lws256.lu.erisoft.se
X-Newsreader:	TIN [version 1.2 PL2]
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Eric Rudd (rudd AT cyberoptics DOT com) wrote:
:   I thought that routines in libc.a could be called 
: from a program compiled either with or without -fomit-frame-pointer, but 
: I found that I could call the existing div.o in libc.a only if I didn't 
: use -fomit-frame-pointer.  Hmm...

If I'm not terribly wrong, that should always work. Either the libc
function uses ebp as frame pointer, in which case it must save it. Or
it doesn't, in which case if it uses ebp to other things it must put
some value it wants there (and save ebp to it doesn't clobber it of
course). So you can't have a bad value in ebp unless the compiler or
the code is broken. And the code is not broken (in that way) as it's
plain C so ebp isn't available to be messed up.

It looks like your gcc or the gcc used to compile libc is broken. And
of those two it most likely is your gcc as different compilations
flags for you make a difference.


Right,

						MartinS

- Raw text -