This is the mail archive of the
mailing list for the eCos project.
[Bug 1001468] eCos GNU tools 4.6.2
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Fri, 3 Feb 2012 08:42:33 +0000
- Subject: [Bug 1001468] eCos GNU tools 4.6.2
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #10 from Ilija Kocho <email@example.com> 2012-02-03 08:42:28 GMT ---
Hi Sergei, thank you for the comments.
(In reply to comment #8)
> Hi Ilija,
> Thank you for your work. Some thoughts if you let.
> It seems for me that we have to discuss/test, get/maintain such a set of
> the patches
> gcc-4.6.2.patch (common fixes for GCC core and g++)
> gcc-4.6.2-<arch>.patch (GCC fixes for <arch> architecture)
> gdb-7.3.1.patch (common fixes for all architectures)
> gdb-7.3.1-<arch>.patch (GDB fixes for <arch> architecture)
> So, minimal set of patches to review and tests for arm targets
> (including your cortex-m4 founds) would be
> gcc-4.6.2.patch, gcc-4.6.2-arm.patch
> gdb-7.3.1.patch, gdb-7.3.1-arm.patch
Generally I find are 3 categories of patches (speaking about GCC):
- Bug fixes/workarounds: (such as LDRD). They are obsolete so I have omitted
- eCos related changes other than multilib: I assume we still want them and
I have applied them verbatim.
- Multilib: This required some creative work and we can expect it to evolve
in future as eCos gets ported to other architectures (I hope for Cortex-A,
Cortex-R). Therefore I have extracted t-arm-elf in a separate file (Attachment
1535) and I would insist keeping it separate.
Further I have separated libgcc and libstfc++ patches. They can probably be
merged back but I think it's better if they stay separate.
> I mean a naming convention (*and splitting*) like used for the patches
> from eCosCentric (you know/work with) which are in Public Domain:
> Then it will be easy to test (apply only needed), review, and track the
> patches for any supported architecture. More that, then we will be able
> to examine any "inter-diffs", looking on 4.3.2 patch set vs 4.6.2 one.
> As I could see the most (all?) smart/tricky things and workarounds for
> 4.3.2 based toolchain from eCosCentric do migrate to new patch set
> (4.6.2). Is it right? Well, I tried to apply old patches for new stuff
> and I got not so many FAILED Hunks as I could expect, but I got a few.
> Thank you that you get rid all of them.
My application was manual, so actually, after some analysis I got rid of some
> Fortunately, the sent patches can be easy joined/split in arch/noarch
> stuffs (there is only one architecture yet) and I would not split fixes
> in GCC 'core' and 'g++' in separate patches (that's mine). What do you
> think? For example, a fix in 'config/host' for arm targets (attachment
> 1538 [details]) I would move to gcc-<version>-arm.patch, etc. IMHO, all fixed
> files under **config/<arch>** directories should be located in a proper
> <arch> patch. And even more, all tweaks for <arch> in GCC core files
> have to be placed also in gcc-4.6.2-<arch>.patch (if that possible).
> Regarding your build scripts. Thank you for sharing it. Unfortunately,
> I could not get what you proposed as configure options for binutils/gcc.
> I mean magic 'configure' options like --enable-*, --disable-*, --with-*,
> --without-* :-)
> For example, I saw behind sha (# --disable-libspp, # --disable-nls, #
> --with-system-zlib, etc) and I misunderstood the reason. I think that
> build scripts are good things to refer for used options (but, in any
> case most from us use own preferences for scripting), so, IMHO, it's
> better just to have 3 long lines with clear options for 3 invokes
> 'configure' here (and for future documentation) instead any build
> scripts. IMHO, the value of one line the options for 'configure' is much
> higher than 100 lines above and below the line :-) So, I will appreciate
> only 3-lines "script" from you and any experts or three 1-line files
> like binutils.configure, gcc.configure, gdb.configure and that will be
> quite enough for testing and discuss.
I have provided the scripts as a reference how I am building GCC (for the time
being). I understand that they may not work in other environment.
Also, that was my first experience with building GCC (when I started it was GCC
4.6.0), and you can find traces of my learning process in scripts.
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.