From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11334 invoked by alias); 24 Jan 2012 23:40:38 -0000 Received: (qmail 11324 invoked by uid 22791); 24 Jan 2012 23:40:37 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_KG X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 23:40:23 +0000 Received: from [77.28.172.52] (port=50468 helo=[192.168.178.36]) by tirion.supremecenter202.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RppyQ-0007ZP-QE; Tue, 24 Jan 2012 23:40:23 +0000 Message-ID: <4F1F4163.3010605@siva.com.mk> Date: Tue, 24 Jan 2012 23:40:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: John Dallaway CC: ecos-maintainers@ecos.sourceware.org Subject: Re: GCC 4.6 resourcing. References: <4F1EF26A.6010201@siva.com.mk> <4F1F265B.2080700@dallaway.org.uk> In-Reply-To: <4F1F265B.2080700@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00003.txt.bz2 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. > > 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? > > 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. >> 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' 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. > 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