This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



-------- 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]