From: Ilija Kocho <ilijak@siva.com.mk>
To: John Dallaway <john@dallaway.org.uk>
Cc: ecos-maintainers@ecos.sourceware.org
Subject: Re: GCC 4.6 resourcing.
Date: Tue, 24 Jan 2012 23:40:00 -0000 [thread overview]
Message-ID: <4F1F4163.3010605@siva.com.mk> (raw)
In-Reply-To: <4F1F265B.2080700@dallaway.org.uk>
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>"
>> 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
next prev parent reply other threads:[~2012-01-24 23:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 18:03 Ilija Kocho
2012-01-24 21:45 ` John Dallaway
2012-01-24 23:40 ` Ilija Kocho [this message]
2012-01-25 6:42 ` Sergei Gavrikov
2012-01-27 14:32 ` Ilija Kocho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1F4163.3010605@siva.com.mk \
--to=ilijak@siva.com.mk \
--cc=ecos-maintainers@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).