croostool-ng: GCC 4.4.1 Working!

croostool-ng: GCC 4.4.1 Working!

[Joachim Nilsson]

Hi everybody!

I managed to get a working armeb-unknown-linux-uclibc toolchain using 
GCC v4.4.1 today.  Yay! :)

We have an Intel IXP465 based CPU board at work that I'm currently 
targeting with my work, but we also have an i.MX27 and sonn possibly 
Arm11 based ones as well.  So I'll be working with crosstool-ng quite a 
bit during the fall and winter months.

Anyway, I used the latest head (correct hg terminology?) of crosstool-ng 
and added the 4.4.1 GCC patches from buildroot:

	http://git.buildroot.net/buildroot/tree/toolchain/gcc/4.4.1

That's about it.

How would I proceed in contributing these patches, inline attachments, 
publish a Mercurial branch, or is it sufficient with the above pointer?

Just curious for any future contributions really.

Regards
  /Jocke

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

Re: croostool-ng: GCC 4.4.1 Working!

[Joachim Nilsson]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On 09/06/2009 01:01 PM, Joachim Nilsson wrote:
> Anyway, I used the latest head (correct hg terminology?) of crosstool-ng
> and added the 4.4.1 GCC patches from buildroot:
> http://git.buildroot.net/buildroot/tree/toolchain/gcc/4.4.1
> That's about it.
> How would I proceed in contributing these patches, inline attachments,
> publish a Mercurial branch, or is it sufficient with the above pointer?

OK, so I don't want to sit on these patches any longer.

Regards
  /Joachim


[-- Attachment #2: patch-support-for-gcc-4.4.1-from-buildroot.diff --]
[-- Type: text/x-patch, Size: 5749 bytes --]

diff -r 3c916825b28d patches/gcc/4.4.1/100-uclibc-conf.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/gcc/4.4.1/100-uclibc-conf.patch	Sat Sep 26 11:53:29 2009 +0200
@@ -0,0 +1,33 @@
+--- gcc/gcc/config/--- gcc/contrib/regression/objs-gcc.sh
++++ gcc/contrib/regression/objs-gcc.sh
+@@ -105,6 +105,10 @@
+  then
+   make all-gdb all-dejagnu all-ld || exit 1
+   make install-gdb install-dejagnu install-ld || exit 1
++elif [ $H_REAL_TARGET = $H_REAL_HOST -a $H_REAL_TARGET = i686-pc-linux-uclibc ]
++ then
++  make all-gdb all-dejagnu all-ld || exit 1
++  make install-gdb install-dejagnu install-ld || exit 1
+ elif [ $H_REAL_TARGET = $H_REAL_HOST ] ; then
+   make bootstrap || exit 1
+   make install || exit 1
+--- gcc/libjava/classpath/ltconfig
++++ gcc/libjava/classpath/ltconfig
+@@ -603,7 +603,7 @@
+ 
+ # Transform linux* to *-*-linux-gnu*, to support old configure scripts.
+ case $host_os in
+-linux-gnu*) ;;
++linux-gnu*|linux-uclibc*) ;;
+ linux*) host=`echo $host | sed 's/^\(.*-.*-linux\)\(.*\)$/\1-gnu\2/'`
+ esac
+ 
+@@ -1251,7 +1251,7 @@
+   ;;
+ 
+ # This must be Linux ELF.
+-linux-gnu*)
++linux*)
+   version_type=linux
+   need_lib_prefix=no
+   need_version=no
diff -r 3c916825b28d patches/gcc/4.4.1/301-missing-execinfo_h.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/gcc/4.4.1/301-missing-execinfo_h.patch	Sat Sep 26 11:53:29 2009 +0200
@@ -0,0 +1,11 @@
+--- gcc-4.0.0/boehm-gc/include/gc.h-orig	2005-04-28 22:28:57.000000000 -0500
++++ gcc-4.0.0/boehm-gc/include/gc.h	2005-04-28 22:30:38.000000000 -0500
+@@ -500,7 +500,7 @@
+ #ifdef __linux__
+ # include <features.h>
+ # if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 1 || __GLIBC__ > 2) \
+-     && !defined(__ia64__)
++     && !defined(__ia64__) && !defined(__UCLIBC__)
+ #   ifndef GC_HAVE_BUILTIN_BACKTRACE
+ #     define GC_HAVE_BUILTIN_BACKTRACE
+ #   endif
diff -r 3c916825b28d patches/gcc/4.4.1/302-c99-snprintf.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/gcc/4.4.1/302-c99-snprintf.patch	Sat Sep 26 11:53:29 2009 +0200
@@ -0,0 +1,13 @@
+Index: gcc-4.3.0/libstdc++-v3/include/c_global/cstdio
+===================================================================
+--- gcc-4.3.0/libstdc++-v3/include/c_global/cstdio	(revision 129202)
++++ gcc-4.3.0/libstdc++-v3/include/c_global/cstdio	(working copy)
+@@ -144,7 +144,7 @@
+ 
+ _GLIBCXX_END_NAMESPACE
+ 
+-#if _GLIBCXX_USE_C99
++#if _GLIBCXX_USE_C99 || defined __UCLIBC__
+ 
+ #undef snprintf
+ #undef vfscanf
diff -r 3c916825b28d patches/gcc/4.4.1/305-libmudflap-susv3-legacy.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/gcc/4.4.1/305-libmudflap-susv3-legacy.patch	Sat Sep 26 11:53:29 2009 +0200
@@ -0,0 +1,49 @@
+Index: gcc-4.2/libmudflap/mf-hooks2.c
+===================================================================
+--- gcc-4.2/libmudflap/mf-hooks2.c	(revision 119834)
++++ gcc-4.2/libmudflap/mf-hooks2.c	(working copy)
+@@ -427,7 +427,7 @@
+ {
+   TRACE ("%s\n", __PRETTY_FUNCTION__);
+   MF_VALIDATE_EXTENT(s, n, __MF_CHECK_WRITE, "bzero region");
+-  bzero (s, n);
++  memset (s, 0, n);
+ }
+ 
+ 
+@@ -437,7 +437,7 @@
+   TRACE ("%s\n", __PRETTY_FUNCTION__);
+   MF_VALIDATE_EXTENT(src, n, __MF_CHECK_READ, "bcopy src");
+   MF_VALIDATE_EXTENT(dest, n, __MF_CHECK_WRITE, "bcopy dest");
+-  bcopy (src, dest, n);
++  memmove (dest, src, n);
+ }
+ 
+ 
+@@ -447,7 +447,7 @@
+   TRACE ("%s\n", __PRETTY_FUNCTION__);
+   MF_VALIDATE_EXTENT(s1, n, __MF_CHECK_READ, "bcmp 1st arg");
+   MF_VALIDATE_EXTENT(s2, n, __MF_CHECK_READ, "bcmp 2nd arg");
+-  return bcmp (s1, s2, n);
++  return n == 0 ? 0 : memcmp (s1, s2, n);
+ }
+ 
+ 
+@@ -456,7 +456,7 @@
+   size_t n = strlen (s);
+   TRACE ("%s\n", __PRETTY_FUNCTION__);
+   MF_VALIDATE_EXTENT(s, CLAMPADD(n, 1), __MF_CHECK_READ, "index region");
+-  return index (s, c);
++  return strchr (s, c);
+ }
+ 
+ 
+@@ -465,7 +465,7 @@
+   size_t n = strlen (s);
+   TRACE ("%s\n", __PRETTY_FUNCTION__);
+   MF_VALIDATE_EXTENT(s, CLAMPADD(n, 1), __MF_CHECK_READ, "rindex region");
+-  return rindex (s, c);
++  return strrchr (s, c);
+ }
+ 
+ /* XXX:  stpcpy, memccpy */
diff -r 3c916825b28d patches/gcc/4.4.1/810-arm-softfloat-libgcc.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/gcc/4.4.1/810-arm-softfloat-libgcc.patch	Sat Sep 26 11:53:29 2009 +0200
@@ -0,0 +1,38 @@
+[PATCH] add the correct symbols to libgcc for uclibc arm softfloat
+
+Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
+---
+ gcc/config/arm/linux-elf.h |    2 +-
+ gcc/config/arm/t-linux     |    6 +++++-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+Index: gcc-4.4.0/gcc/config/arm/t-linux
+===================================================================
+--- gcc-4.4.0.orig/gcc/config/arm/t-linux
++++ gcc-4.4.0/gcc/config/arm/t-linux
+@@ -4,7 +4,11 @@
+ 
+ LIB1ASMSRC = arm/lib1funcs.asm
+ LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx _clzsi2 _clzdi2 \
+-	_arm_addsubdf3 _arm_addsubsf3
++	_arm_addsubdf3 _arm_addsubsf3 \
++	_arm_negdf2 _arm_muldivdf3 _arm_cmpdf2 _arm_unorddf2 \
++	_arm_fixdfsi _arm_fixunsdfsi _arm_truncdfsf2 \
++	_arm_negsf2 _arm_muldivsf3 _arm_cmpsf2 _arm_unordsf2 \
++	_arm_fixsfsi _arm_fixunssfsi
+ 
+ # MULTILIB_OPTIONS = mhard-float/msoft-float
+ # MULTILIB_DIRNAMES = hard-float soft-float
+Index: gcc-4.4.0/gcc/config/arm/linux-elf.h
+===================================================================
+--- gcc-4.4.0.orig/gcc/config/arm/linux-elf.h
++++ gcc-4.4.0/gcc/config/arm/linux-elf.h
+@@ -60,7 +60,7 @@
+    %{shared:-lc} \
+    %{!shared:%{profile:-lc_p}%{!profile:-lc}}"
+ 
+-#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -lgcc"
++#define LIBGCC_SPEC "-lgcc"
+ 
+ #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+ 


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

Re: croostool-ng: GCC 4.4.1 Working!

[Yann E. MORIN]

Joachim,
All,

On Saturday 26 September 2009 17:27:59 Joachim Nilsson wrote:
> On 09/06/2009 01:01 PM, Joachim Nilsson wrote:
> > Anyway, I used the latest head (correct hg terminology?) of crosstool-ng
> > and added the 4.4.1 GCC patches from buildroot:
> > http://git.buildroot.net/buildroot/tree/toolchain/gcc/4.4.1
> > That's about it.
> > How would I proceed in contributing these patches, inline attachments,
> > publish a Mercurial branch, or is it sufficient with the above pointer?
> OK, so I don't want to sit on these patches any longer.

Yes, sorry... I have been a bit lazy the past few days (weeks) wrt
crosstool-NG... It's been threee years now I'm working on it, and
I feel a little bit blasé.

I'm a bit reluctant at applying your patch: there are currently 25 patches
applied to gcc-4.4.0, and I find it odd that 4.4.1 only requires 5.
I will try to forward-port the gcc-4.4.0 patchset up to 4.4.1.

And to answer your question, the README has a quick step-by-step example
on how to submit patches. It boils down to using Mercurial's patchbomb
extension.

Thank you!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



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

Re: croostool-ng: GCC 4.4.1 Working!

[Joachim Nilsson]

On 09/26/2009 10:19 PM, Yann E. MORIN wrote:
>> OK, so I don't want to sit on these patches any longer.
> Yes, sorry... I have been a bit lazy the past few days (weeks) wrt
> crosstool-NG... It's been threee years now I'm working on it, and
> I feel a little bit blasé.

Sorry to hear that, we are a lot of people who really appreciate your 
work!  With your recent move to hg it could perhaps be easier to share 
the burden, so to speak?

Are there anyone else out there willing to help Yann?

I'm still learning, but I could at least start by reading up on hg and 
clone your tree. (I am a bit of a bzr and git man myself though, so I've 
been lazy...)

Maybe the best way for you would be if we set up a better patch approval 
process?  When a new patch is suggested (like mine), some other people 
start evaluating it and give it ++ or --, and if enough people approve 
your job is simply to pull it in?  Not too unlike how Linus does it...

> On Saturday 26 September 2009 17:27:59 Joachim Nilsson wrote:
>> On 09/06/2009 01:01 PM, Joachim Nilsson wrote:
>>> Anyway, I used the latest head (correct hg terminology?) of crosstool-ng
>>> and added the 4.4.1 GCC patches from buildroot:
>>> http://git.buildroot.net/buildroot/tree/toolchain/gcc/4.4.1
>>> That's about it.
>>> How would I proceed in contributing these patches, inline attachments,
>>> publish a Mercurial branch, or is it sufficient with the above pointer?
> I'm a bit reluctant at applying your patch: there are currently 25 patches
> applied to gcc-4.4.0, and I find it odd that 4.4.1 only requires 5.
> I will try to forward-port the gcc-4.4.0 patchset up to 4.4.1.

I see, I was a bit surprised myself when I started looking at how the 
buildroot guys had done it.  I, perhaps wrongly, assumed they had 
already checked if existing patches had been applied upstream.

> And to answer your question, the README has a quick step-by-step example
> on how to submit patches. It boils down to using Mercurial's patchbomb
> extension.

Thanks, you're always too kind!  A simple RTFM would have been 
appropriate in this case. ;-)

Regards
  /Joachim

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

Re: croostool-ng: GCC 4.4.1 Working!

[Yann E. MORIN]

Joachim,
All,

On Monday 28 September 2009 15:40:40 Joachim Nilsson wrote:
> On 09/26/2009 10:19 PM, Yann E. MORIN wrote:
> > Yes, sorry... I have been a bit lazy the past few days (weeks) wrt
> > crosstool-NG... It's been threee years now I'm working on it, and
> > I feel a little bit blasé.
> Sorry to hear that,

I am not planning on abandonning crosstool-NG at all. I just wanted to say
that it has been taking a lot of my time, it is in quite a good shape,
I personnaly have no strong and big improvements I *need*, so development
has slowed down. But I *will* *continue* to maintain and enhance it.

> we are a lot of people who really appreciate your work!

Thanks! :-) Having such feedback is part of the motivation to continue!

> With your recent move to hg it could perhaps be easier to share  
> the burden, so to speak?

Yes, that was part of the plan. Submitting patches should be easier, now.
With correctly formatted patches (eg. sent with the patchbomb extension
to Hg, 'hg email'), it's very simple for me to apply and merge patches.

> Are there anyone else out there willing to help Yann?

In fact, the help I am most in need of is from people with needs I do not
have: canadian, newlib, cygwin target, etc... so they push features and
fixes to features I don't use and corner cases I don't hit.

> I'm still learning, but I could at least start by reading up on hg and 
> clone your tree. (I am a bit of a bzr and git man myself though, so I've 
> been lazy...)

Well, I found Hg to be easier to learn than Git. I never seemed to understand
Git, while switching to Hg was quite straitghforward.

> Maybe the best way for you would be if we set up a better patch approval 
> process?  When a new patch is suggested (like mine), some other people 
> start evaluating it and give it ++ or --, and if enough people approve 
> your job is simply to pull it in?  Not too unlike how Linus does it...

That's a good idea, indeed. We could setup the following process:
- post patch to crosgcc@sourceware... + cc: me
- give a week (or so) for people to comment and rate with '+1' or '-1'
  (-1 requiring a comment).
- after a week, require a majority of 2/3 to apply the patch:
  - if total_ratings < minimum, drop the patch, possibly with comments
  - else if ( positive_ratings / total_ratings ) > (2/3), then apply the patch
  - else, drop the patch, possibly with comments

(minimum is to be tweaked for this list: 10 may be just too many, while
3 may be not enough).

I also receive patches directly, and for those patch I'd answer with smthg
along the lines of:
  Please resend to crossgcc@... and cc me, or your
  patch will be dropped without furher notice.

Do you guys find this approach to be sane?

> > I'm a bit reluctant at applying your patch: there are currently 25 patches
> > applied to gcc-4.4.0, and I find it odd that 4.4.1 only requires 5.
> > I will try to forward-port the gcc-4.4.0 patchset up to 4.4.1.
> I see, I was a bit surprised myself when I started looking at how the 
> buildroot guys had done it.  I, perhaps wrongly, assumed they had 
> already checked if existing patches had been applied upstream.

I have it in a local clone, and it seems to work for my use-case.
I will push later tonight.

> > And to answer your question, the README has a quick step-by-step example
> > on how to submit patches. It boils down to using Mercurial's patchbomb
> > extension.
> Thanks, you're always too kind!  A simple RTFM would have been 
> appropriate in this case. ;-)

Bah, the manual is not so fine! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



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