This is the mail archive of the ecos-maintainers@sourceware.org mailing list for the eCos project.


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

Re: GCC 4.6 resourcing.


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


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