Patchwork [PING] Pass --with-dwarf2 on darwin8

login
register
mail settings
Submitter Jack Howarth
Date Sept. 8, 2010, 1:37 p.m.
Message ID <20100908133759.GA634@bromo.med.uc.edu>
Download mbox | patch
Permalink /patch/64130/
State New
Headers show

Comments

Jack Howarth - Sept. 8, 2010, 1:37 p.m.
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
Mike Stump - Sept. 8, 2010, 10:27 p.m.
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
IainS - Sept. 8, 2010, 10:59 p.m.
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
Jack Howarth - Sept. 8, 2010, 11:18 p.m.
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
Jack Howarth - Sept. 8, 2010, 11:39 p.m.
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
IainS - Sept. 8, 2010, 11:55 p.m.
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
Jack Howarth - Sept. 9, 2010, 1:24 a.m.
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
Mike Stump - Sept. 9, 2010, 11:41 a.m.
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...
Jack Howarth - Sept. 9, 2010, 12:05 p.m.
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...
IainS - Sept. 9, 2010, 12:27 p.m.
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.

Patch

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