Hi David, UBS? Is that the one in Geneva? Anyway, if you compiled with -g and you don't get any more info than that in GDB, I'm not sure what to tell you. That's what I'd expect if you stripped the binary, but not just after a debug build... Are you starting GDB like this: gdb /path/to/app core? Are you running GDB using the installed application, or just a debug version in your build directory? If using an installed version, is it getting stripped during the install process? If so, you might try disabling the stripping so that you don't lose all of your symbol information. Otherwise, I think I've used up my usefulness. :-) Good luck, Lyle -----Original Message----- From: David.Carter-Hitchin [mailto:carterda@xxxxxxx] Sent: Friday, February 20, 2004 11:05 AM To: lrtaylor Cc: gcc-help@xxxxxxxxxxx Subject: RE: C++ Optimization with g++ Hi Lyle, Thanks for the interest you've taken in this little problem. I have tried looking at the core file with gdb, but I didn't get anything meaningful from it. I typed "where" and merely got something like this: # 00000000? at () ?? (That's from memory, so it might be not 100% correct - but it's faily close). That was after compilining with -g (I also tried -g3). Apart from that I don't really know what else to do with a core file. If you've got any good "magic commands" that would be ace if you could share them with me. Some other helpful folk, have offered reams of advice concerning my programming style (or lack thereof), so I'll try their suggestions and post back to this thread when I solve the problem. Many thanks, David Carter-Hitchin, GSD-Risk-IT, UBS Investment Bank On Thu, 19 Feb 2004 lrtaylor@xxxxxxxxxx wrote: > Have you tried looking at a stack trace? If your program is SEGV'ing, > it should be producing a core file (I guess unless you're on Windows). > You can inspect that core file using GDB, including the full stack > (including variable values, etc.) at the time of the crash. That's > usually the first place I look when a program crashes. > > Good luck, > Lyle > > -----Original Message----- > From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On > Behalf Of David.Carter-Hitchin > Sent: Thursday, February 19, 2004 7:13 AM > To: gcc-help@xxxxxxxxxxx > Subject: C++ Optimization with g++ > > Hi, > > I haven't done a great deal of optimization, so apologies in advance for > any > dumb or mis-directed questions. > > I've got this nice little ~5,000 line c++ program at home which plots > the > positions of planets and the Yale Bright Star Catalogue. > > So far so good. > > Scrolling an zooming are fine, but when I swtich the option on to > display > dates (which involves rotating the bitmaps for the textstrings through > 90 > degrees) it runs "like a dog" and I'm not talking greyhound, more like a > three-legged dachshund. > > So I tried putting -O[0123] on and ploop, the program is just warming up > and > then it SEGV's. It seems to be happening at the end of one function > call > (which appears to run fine) or at the very start of another. Compiling > with > -g and running in gdb shows the point, which is just at the final } from > the > last function that works successfully. > > Ultimately I can reprogram the date stuff so I don't have to rotate the > dates on the fly (which is the way I should have done it originally), > but > now I'm curious. > > How can I find out why -O[0123] fails? Is there a strategy I can follow > or doc I should read? Is there a "simple" way of debugging my way out > of > this situation, or is there no alternative to inspecting the assembly? > > gcc version 2.9.something (not threaded). > > All help and clues appreciated. > > Many thanks, > > David Carter-Hitchin, > GSD-Risk-IT, UBS Investment Bank >
