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]

[Bug 1001468] eCos GNU tools 4.6.2

Please do not reply to this email. Use the web interface provided at:

--- Comment #10 from Ilija Kocho <> 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
patches :)

> 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:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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