[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468

--- Comment #8 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-01-31 20:39:20 GMT ---
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

I mean a naming convention (*and splitting*) like used for the patches
from eCosCentric (you know/work with) which are in Public Domain:

 
ftp://sourceware.org/pub/ecos/gnutools/src/ecoscentric-gnutools-20090121-sw-patches.tar.bz2

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.

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) 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.

That was my 2 cents. Thank you.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.