This is the mail archive of the 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.

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

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

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.


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