| Message ID | 20100908133759.GA634@bromo.med.uc.edu |
|---|---|
| State | New |
| Headers | show |
On Sep 8, 2010, at 6:37 AM, Jack Howarth wrote: > Currently on darwin8 users have to explicitly invoke --with-dwarf2 Why? The problem I have with the patch is that in the darwin8 timeframe, dwarf was evolving rapidly and being refined, stabs had the productization and the quality. We know that stabs works well. dwarf was mostly in and working, but might have quality of implementation issues. I don't know that enough testing was put into this change to ensure that there are no regressions, so, for example, did you run the gdb testsuite? Unfortunately, even that, is kinda light. Also, if we did want to changed it, it should be done in darwin8.h, not here. > since it's Xcode defaults to stabs. The attached patch passes --with-dwarf2 > on darwin8 in order to assure it builds the standard dwarf2 support. Okay > for gcc trunk and gcc 4.5.2? > Jack > > 2010-08-12 Jack Howarth <howarth@bromo.med.uc.edu> > > * configure.ac: Pass --with-dwarf2 on darwin8. > * configure: Regenerate. > > > Index: configure.ac > =================================================================== > --- configure.ac (revision 163079) > +++ configure.ac (working copy) > @@ -2506,6 +2506,16 @@ > esac > fi > > +# Default to using --with-dwarf2 on certain targets > +if test x${with_dwarf2} = x ; then > + case "${target}" in > + *-*-darwin8*) > + with_dwarf2=yes; > + extra_host_args="${extra_host_args} --with-dwarf2" > + ;; > + esac > +fi > + > # hpux11 in 64bit mode has libraries in a weird place. Arrange to find > # them automatically. > case "${host}" in > > Thanks in advance. > Jack
On 8 Sep 2010, at 23:27, Mike Stump wrote: > On Sep 8, 2010, at 6:37 AM, Jack Howarth wrote: >> Currently on darwin8 users have to explicitly invoke --with-dwarf2 > Why? Nothing m64 works with stabs, ergo you can't build a working set of multilibs. Also when I last tried it, compare-debug was unreliable for STABs creating some bootstrap problems. Therefore I would recommend to build trunk with dwarf-2 ... ... or to switch off the compare-debug (these were the options I suggested to Jack a while back). FWIW, I don't recall having had any (more serious than usual) issues with dwarf-2 debug on ppc d8. === Having said all of that, I do not believe that we need to change the defaults; STABs is the system selection and not many people (apart from us, perhaps) are trying to build m64 darwin 8. Maybe what we do need to do is to create a wiki page for darwin with information about the various constraints for each version of the system. Someone building trunk on D8 needs to be aware of the trade-offs.. I'll re-try a STABs bootstrap with --disable-multilib sometime and see if it completes. cheers, Iain
On Wed, Sep 08, 2010 at 11:59:19PM +0100, IainS wrote: > > On 8 Sep 2010, at 23:27, Mike Stump wrote: > >> On Sep 8, 2010, at 6:37 AM, Jack Howarth wrote: >>> Currently on darwin8 users have to explicitly invoke --with-dwarf2 >> Why? > > > Nothing m64 works with stabs, ergo you can't build a working set of > multilibs. > Also when I last tried it, compare-debug was unreliable for STABs > creating some bootstrap problems. > > Therefore I would recommend to build trunk with dwarf-2 ... > ... or to switch off the compare-debug (these were the options I > suggested to Jack a while back). > > FWIW, I don't recall having had any (more serious than usual) issues > with dwarf-2 debug on ppc d8. > > === > > Having said all of that, I do not believe that we need to change the > defaults; > > STABs is the system selection and not many people (apart from us, > perhaps) are trying to build m64 darwin 8. > > Maybe what we do need to do is to create a wiki page for darwin with > information about the various constraints for each version of the > system. > Someone building trunk on D8 needs to be aware of the trade-offs.. > > I'll re-try a STABs bootstrap with --disable-multilib sometime and see > if it completes. > > cheers, > Iain Mike and Iain, We do seem to be in a pickle with darwin8. I have had reports from my test gcc45-4.5.1-1000 fink packaging of bootstrap comparison failures on powerpc-apple-darwin8... http://akhmac.blogdns.net/~hansen/finklogs/gcc-4.5.1-1000/fink-build-log_gcc45_4.5.1-1000_10.4-powerpc which were only resolvable by resorting to --with-dwarf2. On the other hand, using that for i386 fink appears to produce unusable x86_64 binarie as you said earlier... http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg20513.html I have not gotten clear feedback as to whether i386 darwin8 suffers from bootstrap comparison failures. Jack
On Wed, Sep 08, 2010 at 11:59:19PM +0100, IainS wrote: > > On 8 Sep 2010, at 23:27, Mike Stump wrote: > >> On Sep 8, 2010, at 6:37 AM, Jack Howarth wrote: >>> Currently on darwin8 users have to explicitly invoke --with-dwarf2 >> Why? > > > Nothing m64 works with stabs, ergo you can't build a working set of > multilibs. > Also when I last tried it, compare-debug was unreliable for STABs > creating some bootstrap problems. > > Therefore I would recommend to build trunk with dwarf-2 ... > ... or to switch off the compare-debug (these were the options I > suggested to Jack a while back). > > FWIW, I don't recall having had any (more serious than usual) issues > with dwarf-2 debug on ppc d8. > > === > > Having said all of that, I do not believe that we need to change the > defaults; > > STABs is the system selection and not many people (apart from us, > perhaps) are trying to build m64 darwin 8. > > Maybe what we do need to do is to create a wiki page for darwin with > information about the various constraints for each version of the > system. > Someone building trunk on D8 needs to be aware of the trade-offs.. > > I'll re-try a STABs bootstrap with --disable-multilib sometime and see > if it completes. > > cheers, > Iain Iain, Unless I am mistaken, I thought the reason that we now see such bootstrap comparison failures is that the list of object files being tested is now expanded in 4.5.1, no? If so, this problem has likely been just been latent. Jack
On 9 Sep 2010, at 00:18, Jack Howarth wrote: I don't think we are in a pickle; We have resource-limitations that prevent us from covering all bases, and the priority is with trunk and darwin >= 9. People trying to build compilers 4, 5, or 6 dot versions later than the system compiler (and intending to retain compatibility with the rest of their system) need to be aware that there might be trade-offs. I have a patch in progress that will hopefully better segregate the differences into respective t-* and *.h files .. > I have not gotten clear feedback as to whether i386 darwin8 suffers > from bootstrap comparison > failures. I last built & reg-tested the 4.5 branch @162448 i686-darwin8 (@m32, --with-dwarf-2) - limited hardware availability - with a priority on trunk. I haven't built powerpc-darwin8 for a while, although I've got a bootstrap of current trunk running on powerpc-darwin7 (using cctools 576, --disable-multilib & STABS). Have you any information on when x86_64 broke on the 4.5 branch ? At present, I am only testing darwin 8 @ m32, Iain
On Thu, Sep 09, 2010 at 12:55:55AM +0100, IainS wrote: > > > Have you any information on when x86_64 broke on the 4.5 branch ? I didn't say that x86_64 broke on 4.5 branch. What I said was that the use of --with-dwarf2 causes issues with the resulting x86_64 binaries on darwin8. See... http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg20515.html Which, as I understood the reports, was trying to use the x86_64 multilib from a i386-apple-darwin8 compiler build. Jack > > At present, I am only testing darwin 8 @ m32, > > Iain
On Sep 8, 2010, at 3:59 PM, IainS wrote: > Nothing m64 works with stabs, ergo you can't build a working set of multilibs. $ gcc -arch ppc64 -c -gstabs t.c $ gcc -arch ppc64 -gstabs t.c -isysroot/Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 $ gdb ./a.out (gdb) ptype f type = float (gdb) ptype d type = double So, clearly, something works. I don't have gmp and the rest of the libs built, so I didn't compile up the top of the tree, but I did compile up the 4_2 branch on my x86 box as a native powerpc-apple-darwin8 build and it built the multilib just fine. Further, it did a stage 2/3 compare and that worked just fine. Does the 4_2 tree build for you? If so, this would be a regression, so the next question would be, what patch regressed the building of the multilib and which regressed the compare? > Also when I last tried it, compare-debug was unreliable for STABs creating some bootstrap problems. Sounds like a darwin8 version of PR41224? If exactly that bug, it is fixed. If not, then I'd say, please file a PR for darwin8 for compare-debug. I think the right approach is for the person that broke that, to suggest a patch forward. Possibly, we just turn off compare debug on ``broken'' systems, and list darwin8 as a broken system (unless dwarf2 is selected of course). > Therefore I would recommend to build trunk with dwarf-2 ... I'd like to retain the option of building stabs... > FWIW, I don't recall having had any (more serious than usual) issues with dwarf-2 debug on ppc d8. Do you debug C++ extensively? Run the gdb testsuite? > Maybe what we do need to do is to create a wiki page Ick. I'd rather turn on dwarf2 than work around it in the doc...
On Thu, Sep 09, 2010 at 04:41:07AM -0700, Mike Stump wrote: > On Sep 8, 2010, at 3:59 PM, IainS wrote: > > Nothing m64 works with stabs, ergo you can't build a working set of multilibs. > > $ gcc -arch ppc64 -c -gstabs t.c > $ gcc -arch ppc64 -gstabs t.c -isysroot/Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 > $ gdb ./a.out > (gdb) ptype f > type = float > (gdb) ptype d > type = double > > So, clearly, something works. I don't have gmp and the rest of the libs built, so I didn't compile up the top of the tree, but I did compile up the 4_2 branch on my x86 box as a native powerpc-apple-darwin8 build and it built the multilib just fine. Further, it did a stage 2/3 compare and that worked just fine. Does the 4_2 tree build for you? If so, this would be a regression, so the next question would be, what patch regressed the building of the multilib and which regressed the compare? Mike, I don't have a darwin8 system to check on, but the offending builds on powerpc 10.4 which fail have been configured as... ../gcc-4.5.1/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.5/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.5 FYI. Jack > > > Also when I last tried it, compare-debug was unreliable for STABs creating some bootstrap problems. > > Sounds like a darwin8 version of PR41224? If exactly that bug, it is fixed. If not, then I'd say, please file a PR for darwin8 for compare-debug. I think the right approach is for the person that broke that, to suggest a patch forward. Possibly, we just turn off compare debug on ``broken'' systems, and list darwin8 as a broken system (unless dwarf2 is selected of course). > > > Therefore I would recommend to build trunk with dwarf-2 ... > > I'd like to retain the option of building stabs... > > > FWIW, I don't recall having had any (more serious than usual) issues with dwarf-2 debug on ppc d8. > > Do you debug C++ extensively? Run the gdb testsuite? > > > Maybe what we do need to do is to create a wiki page > > Ick. I'd rather turn on dwarf2 than work around it in the doc...
On 9 Sep 2010, at 12:41, Mike Stump wrote: > On Sep 8, 2010, at 3:59 PM, IainS wrote: >> Nothing m64 works with stabs, ergo you can't build a working set of >> multilibs. > > $ gcc -arch ppc64 -c -gstabs t.c > $ gcc -arch ppc64 -gstabs t.c -isysroot/Developer/SDKs/ > MacOSX10.4u.sdk -mmacosx-version-min=10.4 > $ gdb ./a.out > (gdb) ptype f > type = float > (gdb) ptype d > type = double > > So, clearly, something works. I shouldn't have said 'nothing' - bad style, sorry; IIRC there is a problem with darwin 8's ld64 and (at least some) stabs in static libs. I don't know if one can reliably repeat the issue with a cross-build from d9/d10 since the ld64 versions are different. > I don't have gmp and the rest of the libs built, so I didn't > compile up the top of the tree, but I did compile up the 4_2 branch > on my x86 box as a native powerpc-apple-darwin8 build and it built > the multilib just fine. Further, it did a stage 2/3 compare and > that worked just fine. Does the 4_2 tree build for you? If so, > this would be a regression, so the next question would be, what > patch regressed the building of the multilib and which regressed the > compare? I built 4.2 native on i686-darwin8 recently but without multilibs - will try again with them enabled. >> Also when I last tried it, compare-debug was unreliable for STABs >> creating some bootstrap problems. > Sounds like a darwin8 version of PR41224? If exactly that bug, it > is fixed. If not, then I'd say, please file a PR for darwin8 for > compare-debug. I think the right approach is for the person that > broke that, to suggest a patch forward. > Possibly, we just turn off compare debug on ``broken'' systems, and > list darwin8 as a broken system (unless dwarf2 is selected of course). maybe we need to use different strip options for darwin-8 .. that could be accommodated in the Darwin) case in debug-compare. >> Therefore I would recommend to build trunk with dwarf-2 ... > > I'd like to retain the option of building stabs... wasn't suggesting removing it -- in fact, I was agreeing with you about leaving it as the default < darwin 9 - but noting that AFAIK you can't expect to build m64 in the general case without dwarf-2. I need to re-check when I can spare a machine - when last I tried >= 4.4 would not bootstrap with dawin8 ppc and stabs (and it seems that people have reported this to Jack, so I guess it hasn't changed). >> FWIW, I don't recall having had any (more serious than usual) >> issues with dwarf-2 debug on ppc d8. > Do you debug C++ extensively? Run the gdb testsuite? no & no - mostly debugging gcc ;-) >> Maybe what we do need to do is to create a wiki page > Ick. I'd rather turn on dwarf2 than work around it in the doc... I was _not_ proposing to work around in the doc. However, there are irrevocable differences in what's available from earlier systems (unless one is prepared to overwrite the system libs and/or apply non-native tools). I think we should record what is possible and what is not (bearing in mind that we have limited time to test the permutations, and limited hardware). e.g. on darwin7 you can build >= 4.4 gcc, objc and fortran but not c++/ objc++ with the native toolset (the linker can't do the necessary coalesced sections for c++ eh). you can build at least 4.6 using cctools xxyyzz from odcctools ... ==== FWIW x86_64 appears broken on darwin8 for 4.5 and trunk - I'm about to try 4.4. Iain.
Index: configure.ac =================================================================== --- configure.ac (revision 163079) +++ configure.ac (working copy) @@ -2506,6 +2506,16 @@ esac fi +# Default to using --with-dwarf2 on certain targets +if test x${with_dwarf2} = x ; then + case "${target}" in + *-*-darwin8*) + with_dwarf2=yes; + extra_host_args="${extra_host_args} --with-dwarf2" + ;; + esac +fi + # hpux11 in 64bit mode has libraries in a weird place. Arrange to find # them automatically. case "${host}" in
Mike, Can I get a review on... Currently on darwin8 users have to explicitly invoke --with-dwarf2 since it's Xcode defaults to stabs. The attached patch passes --with-dwarf2 on darwin8 in order to assure it builds the standard dwarf2 support. Okay for gcc trunk and gcc 4.5.2? Jack 2010-08-12 Jack Howarth <howarth@bromo.med.uc.edu> * configure.ac: Pass --with-dwarf2 on darwin8. * configure: Regenerate. Thanks in advance. Jack