From: Ben Peddell User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: Bug 00314 -- div() still broken References: <3e9c6920$0$21928$afc38c87@> <3EA5477F DOT 2020901 AT cyberoptics DOT com> <3ea85d95$0$12489$4c41069e AT reader1 DOT ash DOT ops DOT us DOT uu DOT net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 39 Message-ID: Date: Fri, 25 Apr 2003 22:00:22 +1000 NNTP-Posting-Host: 144.139.176.186 X-Trace: newsfeeds.bigpond.com 1051271392 144.139.176.186 (Fri, 25 Apr 2003 21:49:52 EST) NNTP-Posting-Date: Fri, 25 Apr 2003 21:49:52 EST Organization: Telstra BigPond Internet Services (http://www.bigpond.com) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eric Rudd wrote: > Ben Peddell wrote: > >> Eric Rudd wrote: >> >>> I think I had some problem with -fomit-frame-pointer, but I'm still >>> investigating. >> >> >> Things are being pushed wrong. >> edi is supposed to hold the address of the div_t structure, yet is has >> 0x28 (40) in it. eax and ebx are supposed to have 40 in them, yet they >> have -3 in them. >> div() wants the stack to look like: >> 16(%ebp): divisor >> 12(%ebp): numerator >> 8(%ebp): &return >> But it appears to look like: >> 16(%ebp): something between -2 and +2 >> 12(%ebp): divisor >> 8(%ebp): numerator >> >> There in lies the problem. > > > This confirms my suspicion that there is a problem with > -fomit-frame-pointer. 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... > > -Eric Rudd > rudd AT cyberoptics DOT com > Obviously, some sort of optimization puts the div_t structure in %edx:%eax instead of 16(%ebp). It would be a good optimization if it didn't break the libraries.