From: acn1 <ac...@ca...> - 2007-12-11 15:54:30
|
I tracked my bug as best I count as put it into the gcc bugzilla. The issue is when gcc tries to move registers it needs to save to the stack and it does so before dropping the stack pointer (ie writuing into a "red zone"). In that case if you call the stack check subroutine its return address is written into the red zone of the stack and can clobber a location where something has been eagerly saved. A week after I had posted my bug with gcc I tracked down where this all happens in config/i386/i386.c and posted a try at a patch, and with that patch applied I now have much better luck. Over in gcc-land my bug remains tagged as UNCONFIRMED and somebody else has checked in changes to i386.c that make different changes but that leave tha patch file I had posted there a little less tidy. I also bet that somebody who understands things better might find a nicer fix than I did (I try to drop back to saving registers only after the stack has moved if the frame will be big and if stack probes are activated, and the patch I put there could probably be done written in a clearer way by introducing a new boolean variable to control when saving is done.... So as best I understand the glitch I had was NOT due to the code within the stack check code being x86 as distinct from x86_64 or any other problems in that, but was down to the fact that ANY procedure being called there did damage.... So please check bug 34013 in the gcc bugzilla, and apologies if that was not teh best place to record what I had found. And many many many thanks for your follow up now! Arthur On Tue, 11 Dec 2007, NightStrike wrote: > On 10/19/07, Kai Tietz <Kai...@on...> wrote: > > Hi Arthur, > > > > > > Did this patch worked for you ? > > > As best I can tell not. > > > Your patch just alters the implementation of the stack check routine, so > > > > > what I have done is to to build a fresh svn version of gcc, then for my > > > bad program cbug.c I go > > > x86_64-pc-mingw32-gcc -O2 -S cbug.s -o cbug.s > > > I then hand edit cbug.s to make cbug1.s and cbug2.s. These explicitly > > save > > > and restore r14 one before the stack check stuff and one after. I can > > then > > > go > > > x86_64-pc-mingw32-gcc cbugX.s -o cbugX > > > and I find that if I save r14 for myself, either before or after > > > stackcheck, that mends things. > > > > > > $ ./cbug > > > 18467 6334 26500 19169 15724 2293356 0000000000000029 4210800 > > > test code here 7538 6782 23454 1887 12012 3912 -22 > > > 18467 4199560 26500 19169 15724 2293356 0000000000000029 4210800 > > > ======= > > > acn1@panamint /d/r38/lisp/csl/fox/x86_64-pc-mingw32/fox-1.6.21/src > > > $ ./cbug1 > > > 18467 6334 26500 19169 15724 2293356 0000000000000029 4210800 > > > test code here 7538 6782 23454 1887 12012 3912 -22 > > > 18467 6334 26500 19169 15724 2293356 0000000000000029 4210800 > > > > > > acn1@panamint /d/r38/lisp/csl/fox/x86_64-pc-mingw32/fox-1.6.21/src > > > $ ./cbug2 > > > 18467 6334 26500 19169 15724 2293356 0000000000000029 4210800 > > > test code here 7538 6782 23454 1887 12012 3912 -22 > > > 18467 6334 26500 19169 15724 2293356 0000000000000029 4210800 > > > > > > It could be that I have messed up and not managed to link in with the > > > updated stack check stuff, and when I have my Linux machine rebuilt and > > > stable again I will try some cross builds there. > > > > > > Arthur[attachment "cbug.c" deleted by Kai Tietz/Onevision] > > > [attachment "cbug.s" deleted by Kai Tietz/Onevision] [attachment > > > "cbug1.s" deleted by Kai Tietz/Onevision] [attachment "cbug2.s" > > > > Ok, I verified the gcc implementation and calling convention for __chkstk > > and anything seems just fine. > > I corrected the two printf in main (I added the argument f, it was > > missing) and I tested your application with ooption -O0 and -O3. I can't > > reproduce your problem at all. Which compiler options did you use ? About > > the subject of r14 I can't follow. __chkstk do not even touch this > > register at all. > > > > May you could provide me more details and I can help you to solve your > > problems. > > Arthur, > > Is your problem solved? > |