From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5132 invoked by alias); 25 Jan 2012 06:42:33 -0000 Received: (qmail 5123 invoked by uid 22791); 25 Jan 2012 06:42:31 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_KG X-Spam-Check-By: sourceware.org Received: from mail-bk0-f49.google.com (HELO mail-bk0-f49.google.com) (209.85.214.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jan 2012 06:42:17 +0000 Received: by bke5 with SMTP id 5so4822695bke.36 for ; Tue, 24 Jan 2012 22:42:16 -0800 (PST) Received: by 10.205.131.142 with SMTP id hq14mr6423783bkc.89.1327473736148; Tue, 24 Jan 2012 22:42:16 -0800 (PST) Received: from sg-pc.belvok.com ([86.57.137.251]) by mx.google.com with ESMTPS id t17sm41881898bke.6.2012.01.24.22.42.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 22:42:14 -0800 (PST) Date: Wed, 25 Jan 2012 06:42:00 -0000 From: Sergei Gavrikov To: Ilija Kocho cc: John Dallaway , ecos-maintainers@ecos.sourceware.org Subject: Re: GCC 4.6 resourcing. In-Reply-To: <4F1F4163.3010605@siva.com.mk> Message-ID: References: <4F1EF26A.6010201@siva.com.mk> <4F1F265B.2080700@dallaway.org.uk> <4F1F4163.3010605@siva.com.mk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00004.txt.bz2 Hi all On Wed, 25 Jan 2012, Ilija Kocho wrote: > On 24.01.2012 22:44, John Dallaway wrote: > > Hi Ilija > > > > Ilija Kocho wrote: > > > > > I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC > > > 4.6.2, Binutils 22.2, GDB 7.3.1) that I would put available for > > > display/review. This is my first such project so I have some > > > questions: > > If you are happy that your arm-eabi toolchain is functional (for > > targets you have at your disposal), then I see no reason not to > > proceed with an initial arm-eabi test release. > > I have tested with Cortex-M targets so far, but the multi-libs seem to > build for same targets as 4.2.3 + additional FPU library for > Cortex-M4. Here's -print-multi-lib diff. > > --- /tmp/multilib_4.3.2.out 2012-01-24 23:25:48.766547367 +0100 > +++ /tmp/multilib_4.6.2.out 2012-01-24 23:25:48.770547367 +0100 > @@ -23,3 +23,4 @@ > thumb/be/nointerwork;@mthumb@mbig-endian@mno-thumb-interwork > thumb/be/xscale;@mthumb@mbig-endian@mcpu=xscale > thumb/be/nointerwork/xscale;@mthumb@mbig-endian@mno-thumb-interwork@mcpu=xscale > +thumb/thumb2/fpu/fpv4spd16;@mthumb@march=armv7@mfloat-abi=hard@mfpu=fpv4-sp-d16 > > It would be wise to try at least ARM7TDMI and ARM9 before we publish, > but I haven't such targets handy. I will be able to test new toolchain on ARM7TDMI (Little-Endian) targets. > > Does the backtrace for an eCos thread and for HAL startup code work > > reliably with GDB 7.3.1? In the past, we have seen issues where the > > backtrace code can enter an infinite loop, hence the patch for GDB > > 6.8.50.x. > > I haven't patched GDB and I haven't tested GDB much, merely used it. > The 7.3.1 rel. notes (and some former releases) mention some fixes > regarding threads... > > How can one produce the case? > > Note: GDB 7.4 has just been released. Should we aim for it or be > little-bit conservative? Also for GDB (for targets is mentioned above). IMHO we have to build and 'i386' toolchain to test GDB 7.X features on Qemu. > > I would definitely recommend building for both Linux x86 and Cygwin > > x86 hosts so we reach all potential testers and get some feedback > > regarding both hosts. > > It would be good to have in mind several Linux distributions: My > current is Ubuntu 10.04 LTS but forthcoming 12.04 is LTS so we should > consider it too. Then Red Hat / Fedora ... > > > > 1. Where shall I put: > > > - Sources > > Since the sources are full binutils/gcc/gdb releases (not > > snapshots), the only real issue is maintaining the patches. > > > > > - Binaries > > Patches and toolchain binaries should be uploaded to the eCos ftp > > area. > > Also http://ecos.sourceware.org/build-toolchain.html shall need > refresh. > > > > 1.1. Regarding sources: > > > I am expecting (hope for) some collaboration so some VCS (CVS would do) > > > would be desirable. This may imply putting complete sources, which may > > > be an overkill... or not... Suggestions? > > I don't think it should be necessary to place the toolchain sources > > under revision control. In the past, we have simply generated tarballs > > containing the various patches and placed them on the ftp site along > > with the generated toolchains. Of course, there should be a separate > > tarball of patches for each version of the toolchain. > > I ask this question in order to define a way of sharing information > during development process. If tarballs do the job then it's OK. We would use Bugzilla report to collect an early set of the patches, opinions, test results, etc. We would "maintain" a collection of the patches there and upload a final tarball on FTP when "issue" will be RESOLVED. > > > 2. Branding > > > IMHO we should mark our tools and the right place is > > > --with-pkgversion (unless it isn't, please see my question > > > below).. > > > > > > My initial proposal is: "eCos Community [GNU]tools 4.6.2-" > > > build = 0, 1, ... > > > [GNU] - optional: GNU | gnu | void > > > Feel free to comment and/or give your own proposals. > > I would suggest something like: > > > > --with-pkgversion='eCos GNU tools 4.6.2-20120124' I like John's version. > Technical question: How do I get the complete (white-space) quote? I > have tried single', double" and backslash/ quoting and it only shows > the first word (eCos) such as: > > 23:55:11> arm-eabi-gcc --version > arm-eabi-gcc (eCos) 4.6.2 > Copyright (C) 2011 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Dash issue? (Guess only). If even ="one\ two" or =one\\ two ... Will be expanded in "one" then try 'bash' as /bin/sh. Check: % readlink /bin/sh. Sergei > > I have suitably old Linux and Cygwin installations here and can > > generate releases based on your patches if you prefer. > > Nice. Your production facilities would be a great help and some > assurance for stable builds. > > > Ilija > >