[Fwd: Re: [PATCH 2 of 3] Add IBM s390 architecture and sample]

Harold Grovesteen h.grovsteen@tx.rr.com
Wed Nov 11 22:58:00 GMT 2009



-------- Original Message --------
Subject: 	Re: [PATCH 2 of 3] Add IBM s390 architecture and sample
Date: 	Wed, 11 Nov 2009 16:30:05 -0600
From: 	Harold Grovesteen <h.grovsteen@tx.rr.com>
To: 	Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
References: 	<e8109b0ff808ea2dc0c7.1257961229@dev.site> 
<200911112012.11588.yann.morin.1998@anciens.enib.fr>



How to get back to a state where there are no patches and I am just 
working from my changes?  Or is that even necessary.

Yann E. MORIN wrote:

>Harold,
>All,
>
>On Wednesday 11 November 2009 18:40:29 Harold Grovesteen wrote:
>  
>
>># HG changeset patch
>># User Harold Grovesteen
>># Date 1257960999 21600
>># Node ID e8109b0ff808ea2dc0c7162ef5db0b1627da32d0
>># Parent  4dfd56aa6ad7b752b3c3c420e350208b631598ce
>>Add IBM s390 architecture and sample
>>    
>>
>
>That's a good commit message! :-)
>
>  
>
>>diff -r 4dfd56aa6ad7 -r e8109b0ff808 config/arch/s390.in
>>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>+++ b/config/arch/s390.in	Wed Nov 11 11:36:39 2009 -0600
>>@@ -0,0 +1,12 @@
>>+# s390 specific config options
>>+# depends on EXPERIMENTAL
>>+
>>+config ARCH_s390
>>+    select ARCH_USE_MMU
>>+    select ARCH_SUPPORT_FPU
>>+    select ARCH_DEFAULT_HAS_MMU
>>+    select ARCH_DEFAULT_BE
>>+    select CT_THREAD
>>+    help
>>+      The IBM ESA/390 architecture, as defined by:
>>+        http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar008/CCONTENTS
>>    
>>
>
>Good, that's a nice architecture definition.
>
>  
>
>>diff -r 4dfd56aa6ad7 -r e8109b0ff808 samples/s390-ibm-linux-gnu/crosstool.config
>>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>+++ b/samples/s390-ibm-linux-gnu/crosstool.config	Wed Nov 11 11:36:39 2009 -0600
>>    
>>
>[--SNIP--]
>  
>
>>+# crosstool-NG behavior
>>+#
>>+# CT_OBSOLETE is not set
>>+CT_EXPERIMENTAL=y
>>+CT_DEBUG_CT=y
>>+# CT_DEBUG_PAUSE_STEPS is not set
>>+CT_DEBUG_CT_SAVE_STEPS=y
>>+CT_DEBUG_CT_SAVE_STEPS_GZIP=y
>>    
>>
>
>Please, turn off any debug feature in samples
>
Will fix.

>[--SNIP--]
>  
>
>>+# Extracting
>>+#
>>+# CT_FORCE_EXTRACT is not set
>>+CT_OVERIDE_CONFIG_GUESS_SUB=y
>>+# CT_ONLY_EXTRACT is not set
>>+# CT_PATCH_BUNDLED is not set
>>+CT_PATCH_LOCAL=y
>>+# CT_PATCH_BUNDLED_LOCAL is not set
>>+# CT_PATCH_LOCAL_BUNDLED is not set
>>+# CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set
>>+# CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set
>>+CT_PATCH_ORDER="local"
>>+# CT_PATCH_SINGLE is not set
>>+CT_PATCH_USE_LOCAL=y
>>+CT_LOCAL_PATCH_DIR="$HOME/crosstool/patches"
>>    
>>
>
>If you have local patches you do not include in crosstool-NG, then the
>sample is useless. Please add the patches in crosstool-NG.
>
No, local patches.  When I started I put this in the config in case I 
needed any.  Just needs to be cleaned up.

>[--SNIP--]
>  
>
>>+# General target options
>>+#
>>+# CT_ARCH_alpha is not set
>>+# CT_ARCH_arm is not set
>>+# CT_ARCH_avr32 is not set
>>+# CT_ARCH_ia64 is not set
>>+# CT_ARCH_mips is not set
>>+# CT_ARCH_powerpc64 is not set
>>+# CT_ARCH_powerpc is not set
>>+CT_ARCH_s390=y
>>+# CT_ARCH_s390x is not set
>>    
>>
>
>s390x support is not yet in (comes with the next patch), so rework
>the sample to be "clean".
>
By "clean" do you mean that the statement needs to be removed from the 
sample before patching?

>[--SNIP--]
>  
>
>>+# C compiler
>>    
>>
>[--SNIP--]
>  
>
>>+CT_CC_EXTRA_CONFIG="--with-tls --with-__thread"
>>    
>>
>
>I'm uneasy with those. Are they really needed? Normally, the ./configure
>for gcc will automatically detect if TLS and threads are supported, and
>it should not be needed to manually specify them.
>
I had used crosstool.  Wanting to start with a somewhat known state, I 
may have added these because crosstool used them in its configure.  I 
will remove and retest.  Any suggestion as to how to determine if the 
correct settings are used would be appreciated.  A clean run would not 
prove the correct settings were used.  Any suggestion as to how to 
determine if the correct settings are used would be appreciated.

>  
>
>>+# CT_DEBUG_dmalloc is not set
>>    
>>
>
>You provide a patch against dmalloc (in a previous mail), but don't
>use it? How did you conclude that dmalloc needed that patch (when in
>fact it definitely does not) ?
>
As I mentioned previously, I never got dmalloc to compile and gave up on 
the other debug tools.  The patch should be removed.
How do I eliminate this patch from being created?

>[--SNIP--]
>  
>
>>diff -r 4dfd56aa6ad7 -r e8109b0ff808 scripts/build/arch/s390.sh
>>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>>+++ b/scripts/build/arch/s390.sh	Wed Nov 11 11:36:39 2009 -0600
>>@@ -0,0 +1,8 @@
>>+# Compute s390-specific values
>>+
>>+CT_DoArchTupleValues() {
>>+    # The architecture part of the tuple:
>>+    CT_TARGET_ARCH="s390"
>>+    CT_KERNEL_ARCH="s390"
>>    
>>
>
>Do not change CT_TARGET_ARCH and CT_KERNEL_ARCH: you only need to do so if
>the real architecture name does not match the configure name (that appears
>in the menus). In your case, you don't need to
>
Did not know that.  I simply read the architecture section in the 
overview.txt which seemed to indicate I needed to do this.  Will remove.

>  
>
>>+    #CT_DEBUG_CT_SAVE_STEPS="y"
>>    
>>
>
>Remove debug/unneeded code.
>
Will do so with the other cleanup.

>  
>
>>+}
>>    
>>
>
>All-in-all, that's quite correct. Can you address all those issues, please?
>Keep up the work, we'll manage something! :-)
>
Happily and appreciate the feedback.

>Regards,
>Yann E. MORIN.
>
>  
>


--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list