Yes, but say I'm using a custom built version of gcc that doesn't do -gstabs quite right. Now you've screwed me. I'm a firm believer that our configure script should do what the user says, as exactly as possible. Changing AC behavior a little bit is a gray area, but one I'm almost ok with (since AC_PROG_CC will add -g if CFLAGS is empty).
Brian On Jul 27, 2010, at 2:59 PM, Jeff Squyres wrote: > My thought was that if you specified "-g", you probably wanted -gstabs+. > Indeed, for years, I didn't know that -gstabs+ was required on OS X to make > debugging symbols work in gdb... > > > On Jul 27, 2010, at 3:43 PM, Barrett, Brian W wrote: > >> Sorry for not replying sooner, I was on vacation the last couple of days. >> >> Ew - why do it that way? If I as a user specified -g, I sure don't want >> that to magically become -gstabs. Overriding Autoconf's addition of -g with >> -gstabs+ is fine, but overriding what the user says is just wrong. >> >> Brian >> >> On Jul 26, 2010, at 9:07 AM, Jeff Squyres wrote: >> >>> Ok; a commit is queued up for the trunk tonight that should do this: >>> >>> - If we're on Darwin >>> - And -g is in CFLAGS already >>> - Then do a test compile to see if -gstabs+ works >>> - If it does, then add it to CFLAGS >>> - Then double check and uniq-ify CFLAGS (to ensure -gstabs+ wasn't in there >>> already) >>> >>> >>> On Jul 25, 2010, at 7:52 AM, Ralph Castain wrote: >>> >>>> I can't speak for totalview, but as a developer on Darwin, adding -gstabs+ >>>> enables the clean use of gdb and would help immensely! >>>> >>>> >>>> On Jul 15, 2010, at 8:14 AM, Jeff Squyres wrote: >>>> >>>>> Resurrecting this orphaned discussion... >>>>> >>>>> Peter: so what exactly do you need? -gstabs or -gstabs+ when compiling >>>>> these files on Darwin? (or, more specifically, whenever the back-end >>>>> compiler supports one/both of these flags) >>>>> >>>>> >>>>> On Jun 9, 2010, at 11:43 PM, Paul H. Hargrove wrote: >>>>> >>>>>> >>>>>> >>>>>> Jeff Squyres wrote: >>>>>>> On Jun 4, 2010, at 5:02 PM, Peter Thompson wrote: >>>>>>> >>>>>>> >>>>>>>> It was suggested by our CTO that if these files were compiled as to >>>>>>>> produce STABS debug info, rather than DWARF, then the debug info would >>>>>>>> be copied into the executables and shared libraries, and we would then >>>>>>>> be able to debug with Open MPI without a problem. I'm not sure if >>>>>>>> this >>>>>>>> is the best place to offer that suggestion, but I imagine it's not a >>>>>>>> bad >>>>>>>> place to start. ;-) >>>>>>>> >>>>>>> >>>>>>> Having just moved this to the "devel" list... >>>>>>> >>>>>>> I don't think we'd mind doing what you propose if it's not too icky. >>>>>>> These files are explicitly there for debuggers like TV, after all. >>>>>>> >>>>>>> So how do we do that? (I don't know anything about STABS or DWARF) >>>>>>> >>>>>>> >>>>>> >>>>>> Extracted from "man gcc" on Darwin host: >>>>>> >>>>>> >>>>>> -gstabs >>>>>> Produce debugging information in stabs format (if that is >>>>>> supported), without GDB >>>>>> extensions. This is the format used by DBX on most BSD >>>>>> systems. On MIPS, Alpha and >>>>>> System V Release 4 systems this option produces stabs >>>>>> debugging output which is not >>>>>> understood by DBX or SDB. On System V Release 4 systems this >>>>>> option requires the GNU >>>>>> assembler. >>>>>> >>>>>> -gstabs+ >>>>>> Produce debugging information in stabs format (if that is >>>>>> supported), using GNU >>>>>> extensions understood only by the GNU debugger (GDB). The >>>>>> use of these extensions is >>>>>> likely to make other debuggers crash or refuse to read the >>>>>> program. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Paul H. Hargrove phhargr...@lbl.gov >>>>>> Future Technologies Group >>>>>> HPC Research Department Tel: +1-510-495-2352 >>>>>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >>>>>> >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> de...@open-mpi.org >>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> jsquy...@cisco.com >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>> >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> >> -- >> Brian W. Barrett >> Dept. 1423: Scalable System Software >> Sandia National Laboratories >> >> >> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
