[Bug 1001468] New: eCos GNU tools 4.6.2

[Bug 1001468] New: eCos GNU tools 4.6.2

[bugzilla-daemon]

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

           Summary: eCos GNU tools 4.6.2
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: Other
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org
             Group: eCos
             Class: Advice Request


eCos GNU tools 4.6.2

Components:
    GCC 4.6.2 (needs patches for eCos, - Multilib, etc)
        gcc-core
        gcc-g++
    Binutils 2.22
    GDB 7.3.1 (needs eCos back-trace patch)

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:54:45 GMT ---
Created an attachment (id=1535)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1535)
eCos Multilib configuration 20110125

This file is separated in it's own file in order to facilitate eventual changes
to multilib configuration.

New since ver 4.3.2

Added library configuration for FPv4-SP-D16-M, FPU found on Cortex-M4F cores.
--- /tmp/multilib_4.3.2.out    2012-01-28 18:53:50.744015282 +0100
+++ /tmp/multilib_4.6.2.out    2012-01-28 18:53:50.748015282 +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

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:57:37 GMT ---
Created an attachment (id=1536)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1536)
ARM GCC patches

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:58:55 GMT ---
Created an attachment (id=1537)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1537)
General GCC configuration patches 20110125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:00:00 GMT ---
Created an attachment (id=1538)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1538)
libgcc patches 20110125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:01:21 GMT ---
Created an attachment (id=1539)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1539)
libstdc++-v3 patches 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:02:25 GMT ---
Created an attachment (id=1540)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1540)
gdb 7.3.1. back-trace patch 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1535|eCos Multilib configuration |eCos Multilib configuration
        description|20110125                    |20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1536|ARM GCC patches             |ARM GCC patches 20120125
        description|                            |

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1537|General GCC configuration   |General GCC configuration
        description|patches 20110125            |patches 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1538|libgcc patches 20110125     |libgcc patches 20120125
        description|                            |

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:13:26 GMT ---
Created an attachment (id=1541)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1541)
Build scripts 20120125

Here are my building scripts for reference.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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 on the CC list for the bug.

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-01-31 20:55:43 GMT ---
In comment #8 read

  a fix in 'config.host'

instead of

  a fix in 'config/host'

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 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
them.

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

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. 

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #11 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-03 18:54:25 GMT ---
(In reply to comment #10)

Hi Ilija,

[snip]

> Generally I find are 3 categories of patches (speaking about GCC):
>    - Bug fixes/workarounds: (such as LDRD). They are obsolete so I
>    have omitted them.

Good to know. Thank you for dive in.

>    - eCos related changes other than multilib: I assume we still want
>    them and I have applied them verbatim.

It looks like that. It seemed to me that they knew what they done
(fixed). They are strong experts.

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

May be for now, but, (IMHO) all tweaks for any architecture must be
accumulated *at the end* in a final gcc-4.6.2-<arch>.patch. However, it
is not issue for me if you do prefer small deltas to apply.

> 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 think this is no problem. A matter of taste. But I would combine all
common things (for c/c++) in one gcc-4.6.2.patch.

[snip]

> > 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-* :-)

[snip]

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

Fortunately, gcc stores its configure options:

  % <target>-gcc -v

Thus, you can use (for start) configure options for GCC 4.3.2 from
eCosCentric. As you can see eCosCentric built and some cross tools
(libraries) as gmp, mpfr; it seems to me it must be used for the GCC
4.6.2 build too to prevent the host's dependencies and may be it will
need more (or less) libraries (need to investigate).

Ilija, I will try to build new toolchain for i386 architecture. It's
easier to build (less time to wait for :-) and test for me and then I
will share the got configure options and any "finds" for the build
here.

Sergei

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-04 19:39:38 GMT ---
(In reply to comment #11)

> Thus, you can use (for start) configure options for GCC 4.3.2 from
> eCosCentric. As you can see eCosCentric built and some cross tools
> (libraries) as gmp, mpfr; it seems to me it must be used for the GCC
> 4.6.2 build too to prevent the host's dependencies and may be it will
> need more (or less) libraries (need to investigate).

It was much easier to find dependences than I thought. Required items to
build GCC 4.6.2 are described in GCC documentation :-)

 gcc-4.6.2/INSTALL/prerequisites.html

It seems to me GCC build requires GMP, MPFR, MPC libraries (Necessary to
Build GCC). So, these libraries look like SHOULD requirements.  And PPL,
CLooG (IMHO) look like COULD requirements (Necessary to build GCC with
the Graphite loop optimizations), and may be even WON'T requirement for
eCos.

Sergei

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #13 from John Dallaway <john@dallaway.org.uk> 2012-02-06 09:15:56 GMT ---
I now have a portable build of the arm-eabi toolchain for i686-pc-linux-gnu
hosts, but the build for i686-pc-cygwin hosts is proving to be a problem. There
is an issue with building libiberty with my Cygwin installation. I would prefer
to release the initial test toolchain for both hosts together if possible. I'm
checking the mailing lists...

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 16:23:05 GMT ---
(In reply to comment #11)
> Ilija, I will try to build new toolchain for i386 architecture. It's
> easier to build (less time to wait for :-) and test for me and then I will
> share the got configure options and any "finds" for the build here.

(In reply to comment #12)
> It seems to me GCC build requires GMP, MPFR, MPC libraries (Necessary to
> Build GCC). So, these libraries look like SHOULD requirements.  And PPL,
> CLooG (IMHO) look like COULD requirements (Necessary to build GCC with the
> Graphite loop optimizations), and may be even WON'T requirement for eCos.

For now I stick at such an option set for 'i386-elf' target:

  % i386-elf-gcc -v
  Using built-in specs.
  COLLECT_GCC=i386-elf-gcc
 
COLLECT_LTO_WRAPPER=/home/test/gnutools/i386-elf/libexec/gcc/i386-elf/4.6.2/lto-wrapper
  Target: i386-elf
  Configured with: /home/test/build/gcc-4.6.2/configure -v
--with-pkgversion='eCos GNU tools 4.6.2-1'
--with-bugurl=http://bugs.ecos.sourceware.org --enable-languages=c,c++
--prefix=/home/test/gnutools/i386-elf --enable-threads --with-gnu-as
--with-gnu-ld --with-newlib --with-mpfr=/home/test/gnutools/tools
--with-gmp=/home/test/gnutools/tools --with-mpc=/home/test/gnutools/tools
--disable-__cxa_atexit --disable-hosted-libstdcxx --disable-decimal-float
--disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath
--disable-multilib --disable-nls --disable-shared --target=i386-elf
  Thread model: single
  gcc version 4.6.2 (eCos GNU tools 4.6.2-1)

NOTES

1) A bit modified patches for 4.3.2 from eCosCentric were applied for 4.6.2
sources;

2) HOSTCC was i486-linux-gnu-gcc.

Q: Do we interested in the builds (tests) pass itself on x86_64 hosts?

Well, I liked that new compilers do produce no new warnings, but

  [-Wunused-but-set-variable]

So, we have a straightforward solution to fix all them :-)  So far, I tested
only builds for eCos default template +FILEIO +USTL. New GDB has not been
tested yet (I think this can take the next weekend).

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 20:51:29 GMT ---
(In reply to comment #13)
> I now have a portable build of the arm-eabi toolchain for
> i686-pc-linux-gnu hosts, but the build for i686-pc-cygwin hosts is
> proving to be a problem. There is an issue with building libiberty
> with my Cygwin installation. I would prefer to release the initial
> test toolchain for both hosts together if possible. I'm checking the
> mailing lists...

Hi John,

If the issue is building *GCC* libiberty, you would try to use this
one from Binutils as I found other do it

http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html
http://www.linuxquestions.org/questions/linux-software-2/compiling-gcc-4-5-2-without-libiberty-917624/

Sergei

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #16 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 21:53:30 GMT ---
(In reply to comment #15)
> > I now have a portable build of the arm-eabi toolchain for
> > i686-pc-linux-gnu hosts, but the build for i686-pc-cygwin hosts is
> > proving to be a problem. There is an issue with building libiberty
> > with my Cygwin installation. I would prefer to release the initial
> > test toolchain for both hosts together if possible. I'm checking the
> > mailing lists...
> 
> If the issue is building *GCC* libiberty, you would try to use this
> one from Binutils as I found other do it
> 
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html
> http://www.linuxquestions.org/questions/linux-software-2/compiling-gcc-4-5-2
> -without-libiberty-917624/

Yet another story (in Japanese) [Excuse my posts if you read all already]

  http://www5.ocn.ne.jp/~tane/prog/win/howtobuildtools.html

NOTE: As for me Google Translate translated the page (URL -> autodetect
lang) just fine.

There is described how Tane built the same cross tools (2.22+4.6.2) for
PowerPC target on *Cygwin* host there. There are all configure options
for that and Tane also points on LFS project. Though, I read Cross-LFS
"books" (cross-lfs.org) + looked at some SlackBuild scripts when worked
on my build script.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #17 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-14 20:25:35 GMT ---
Hi

Ilija, John - many thanks for new GNU tools and patches for arm-eabi
targets.

I'm checking my build for arm-eabi and I would like to verify some
things. Has anyone kept a log file on configure/build GCC for arm-eabi?

I am concerned about some warnings on configure libstdc++ libraries ...

  checking for atomic builtins for bool... no
  checking for atomic builtins for short... no
  checking for atomic builtins for int... no
  checking for atomic builtins for long long... no
  configure: WARNING: No native atomic operations are provided for this
platform.
  configure: WARNING: They cannot be faked when thread support is disabled.
  configure: WARNING: Thread-safety of certain classes is not guaranteed.

Have you seen these warnings? If you have not, what was your score

  % grep WARNING build.log | wc -l

I afraid that I get a spurious build...

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #18 from John Dallaway <john@dallaway.org.uk> 2012-02-14 22:07:20 GMT ---
(In reply to comment #17)

> I am concerned about some warnings on configure libstdc++ libraries ...
> 
>   checking for atomic builtins for bool... no
>   checking for atomic builtins for short... no
>   checking for atomic builtins for int... no
>   checking for atomic builtins for long long... no
>   configure: WARNING: No native atomic operations are provided for this
> platform.
>   configure: WARNING: They cannot be faked when thread support is disabled.
>   configure: WARNING: Thread-safety of certain classes is not guaranteed.
> 
> Have you seen these warnings? If you have not, what was your score

We build only libsupc++ from the libstdc++-v3 package. libsupc++ provides 'new'
and 'delete' and these will use the eCos memory allocator.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-21 20:36:45 GMT ---
FYI

This weekend I tested a bit new distributed binaries for arm-eabi and
also the built toolchains from sources for x86_64 and i686 Linux hosts.
An ARM7TDMI target was used for testing. All built eCos tests ran under
GDB (it was used a fresh build of RedBoot for that). I have chosen such
a template for testing

  cdl_configuration eCos {
      template    default ;
      package CYGPKG_IO_FILEIO current ;
      package CYGPKG_USTL current ;
      package CYGPKG_COMPRESS_ZLIB current ;
      package CYGPKG_CRC current ;
      package CYGPKG_FS_RAM current ;
      package CYGPKG_POSIX current ;
  };

All three batch (run of 214 eCos tests) shown the same results:

  PASS:           1123
  NOT APPLICABLE: 6
  FAIL:           0

NOTE: USTL bvt13, bvt17 tests were rejected from the batch run (they
expect an input), bvt05 was adopted to fit amount of RAM on the target.

Of course, it was not stress and complete testing, there was not NET
stuff in eCos configuration, but, at the least I found no issues on my
arm7tdmi target with new toolchains on Linux box.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #20 from John Dallaway <john@dallaway.org.uk> 2012-02-24 12:28:31 GMT ---
(In reply to comment #19)

> This weekend I tested a bit new distributed binaries for arm-eabi and
> also the built toolchains from sources for x86_64 and i686 Linux hosts.

Sergei, thank you for the testing with arm-eabi target. Do you think it would
be useful to generate a similar "test release" for i386-elf target? The eCos
GCC patch for i386 looks like it would be easy to migrate from GCC 4.3.2 to GCC
4.6.2.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #21 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-24 12:48:06 GMT ---
(In reply to comment #20)
> (In reply to comment #19)
> 
> > This weekend I tested a bit new distributed binaries for arm-eabi
> > and also the built toolchains from sources for x86_64 and i686 Linux
> > hosts.
> 
> Sergei, thank you for the testing with arm-eabi target. Do you think
> it would be useful to generate a similar "test release" for i386-elf
> target? The eCos GCC patch for i386 looks like it would be easy to
> migrate from GCC 4.3.2 to GCC 4.6.2.

I have built i386-elf toolchain, but not tested it yet. As I used the
latest mpfr/mpc/gmp,  I shall rebuild the tools with your set of the
libraries, and then I will test got eCos executables on Qemu. I hope I
will finish testing this weekend.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #22 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-26 16:28:30 GMT ---
(In reply to comment #21)
> I have built i386-elf toolchain, but not tested it yet. As I used the
> latest mpfr/mpc/gmp,  I shall rebuild the tools with your set of the
> libraries, and then I will test got eCos executables on Qemu. I hope I
> will finish testing this weekend.

Go flop. The first issue is a built RedBoot (4.6.2) could not assist to
run built eCos tests (4.6.2) under GDB (7.3.1). I have no ideas what was
wrong with that as the same RedBoot sources are built with (GCC-4.3.2)
provide GDB support for new eCos tests (built with GCC-4.6.2) in GDB
7.3.1, and the second issue is that the build tests (with GDB-4.6.2) had
.text segments more bloat (1.1 ~ 1.2) than the same builds are built
with GCC-4.3.2. Though one patch was applied to config/i386/i386elf.h

  ---
   gcc-4.6.2/gcc/config/i386/i386elf.h |    4 ----
   1 file changed, 4 deletions(-)

  --- a/gcc-4.6.2/gcc/config/i386/i386elf.h
  +++ b/gcc-4.6.2/gcc/config/i386/i386elf.h
  @@ -20,10 +20,6 @@
   along with GCC; see the file COPYING3.  If not see
   <http://www.gnu.org/licenses/>.  */

  -/* Use stabs instead of DWARF debug format.  */
  -#undef  PREFERRED_DEBUGGING_TYPE
  -#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
  -
   #define TARGET_VERSION fprintf (stderr, " (i386 bare ELF target)");

   /* The ELF ABI for the i386 says that records and unions are returned

It seems to me that I cannot propose to s/4.3.2/4.6.2/ for i386 :-( BTW,
mpfr/mpc/gmp versions were not an issue (I had the same results with the
newest libraries and with stable ones).

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #23 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-26 16:49:12 GMT ---
(In reply to comment #22)
> 7.3.1, and the second issue is that the build tests (with GDB-4.6.2) had
                                                            ^^^^^^^^^
Should read                                                 GCC-4.6.2

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #24 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-28 14:03:54 GMT ---
(In reply to comment #22)
> Go flop. The first issue is a built RedBoot (4.6.2) could not assist
> to run built eCos tests (4.6.2) under GDB (7.3.1). I have no ideas
> what was wrong with that as the same RedBoot sources are built with
> (GCC-4.3.2) provide GDB support for new eCos tests (built with
> GCC-4.6.2) in GDB

[snip]

>From my tests RedBoot+GDB on Qemu, the builds of RedBoot for i386 with
default eCos CFLAGS (-g -O2) are "broken" (I got spurious SIGINT after
any diagnostic output in GDB), but, I found that all *not optimized*
RedBoot builds work without such an issue.  Thus, I do not know can I
trust that GCC 4.6.2 build for i386-elf target with that minimal patch.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-02 16:19:22 GMT ---
2012/03/01 GCC 4.6.3 released (http://sourceware.org/gcc/)

As they said GCC 4.6.3 is a bug-fix release for GCC 4.6.2.

I looked at its PR list

 
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3

Well, in main I search for /arm bug-fix reports. My concern is a bug

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641

This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
patch to our new arm-eabi toolchain (4.6.2 based)? What is your opinion? 

FYI 

Good news that I did not meet such gas warnings when I tested GCC 4.6.2
on my board, bad ones that it is possible to get it for other targets,
or ARM7 (armv4) cpus.

I just s/4.6.2/4.6.3/ for my build script and it was possible to build
arm-eabi toolchain (4.6.3). There were no hunks/fails for used patches.
However, I have not tested yet new toolchain on real hardware.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #26 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-03 13:47:31 GMT ---
(In reply to comment #25)
> 2012/03/01 GCC 4.6.3 released (http://sourceware.org/gcc/)
> 
> As they said GCC 4.6.3 is a bug-fix release for GCC 4.6.2.
> 
> I looked at its PR list
> 
>  
> http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3
> 
> Well, in main I search for /arm bug-fix reports. My concern is a bug
> 
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
> 
> This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
> patch to our new arm-eabi toolchain (4.6.2 based)? What is your opinion? 

If the bug is so severe that we must have a fix, considering that we're just
beginning with 4.6, I would consider 4.6.3 rather than a patch.

Otherwise there will be 4.6.minors in future an we can't follow them all.

> 
> FYI 
> 
> Good news that I did not meet such gas warnings when I tested GCC 4.6.2
> on my board, bad ones that it is possible to get it for other targets,
> or ARM7 (armv4) cpus.
> 
> I just s/4.6.2/4.6.3/ for my build script and it was possible to build
> arm-eabi toolchain (4.6.3). There were no hunks/fails for used patches.

Probably the same patches will be applicable without hunk-fails to any
4.6.minor. FYI they stem back from 4.6.0.


> However, I have not tested yet new toolchain on real hardware.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #27 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-03 14:30:11 GMT ---
(In reply to comment #26)
> > Well, in main I search for /arm bug-fix reports. My concern is a bug
> > 
> >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
> > 
> > This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
> > patch to our new arm-eabi toolchain (4.6.2 based)? What is your
> > opinion? 
> 
> If the bug is so severe that we must have a fix, considering that
> we're just beginning with 4.6, I would consider 4.6.3 rather than a
> patch.

Agreed. But if that will be really needed. I would trust the eCosCentric
test results for ARM7 target.

> Otherwise there will be 4.6.minors in future an we can't follow them
> all.

It's clear. I did not suggest to follow all next 4.6 derivatives.

> > Good news that I did not meet such gas warnings when I tested GCC
> > 4.6.2 on my board, bad ones that it is possible to get it for other
> > targets, or ARM7 (armv4) cpus.
> > 
> > I just s/4.6.2/4.6.3/ for my build script and it was possible to
> > build arm-eabi toolchain (4.6.3). There were no hunks/fails for used
> > patches.
> 
> Probably the same patches will be applicable without hunk-fails to any
> 4.6.minor. FYI they stem back from 4.6.0.

Good to know.

> > However, I have not tested yet new toolchain on real hardware.

Today I tested a bit and GCC 4.6.3 based build (just for case)
http://ecos.sourceware.org/ml/ecos-devel/2012-03/msg00002.html

And as I told I had no problems with the contributed toolchain too,
though, my test "farm" is a very little farm (1-board stall), so, I
decided to point on that bug-fix here.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #28 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-03 19:46:17 GMT ---
At the end I found that bug 49641.  I missed it, because STMIA is THUMB
instruction :-) and I never force such option:

  cdl_option CYGHWR_THUMB {
      user_value 1
  };

Well, is unreal config for me, but:

    CC    ip_input.c
  /tmp/cceuQCd7.s: Assembler messages:
  /tmp/cceuQCd7.s:834: Warning: value stored for r3 is UNKNOWN

disassemble output with objdump:

  /tmp/t/net/bsd_tcpip/current/src/sys/netinet/net_bsd_tcpip_ip_icmp.o:
     6:    c30c          stmia    r3!, {r2, r3}

I checked that GCC 4.6.3 does not produce such error(s) with the same
eCos config.

So, if someone build applications with '-mthumb' then in theory he can
catch the GCC bug #49641 if it was used arm-eabi GCC 4.6.{1,2}.

Thus, IMHO, we have to switch to GCC-4.6.3 code base.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #29 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-03 21:17:31 GMT ---
(In reply to comment #28)
> At the end I found that bug 49641.  I missed it, because STMIA is THUMB
> instruction :-) and I never force such option:
> 
>   cdl_option CYGHWR_THUMB {
>       user_value 1
>   };
> 
> Well, is unreal config for me, but:
> 
>     CC    ip_input.c
>   /tmp/cceuQCd7.s: Assembler messages:
>   /tmp/cceuQCd7.s:834: Warning: value stored for r3 is UNKNOWN
> 
> disassemble output with objdump:
> 
>   /tmp/t/net/bsd_tcpip/current/src/sys/netinet/net_bsd_tcpip_ip_icmp.o:
>      6:    c30c          stmia    r3!, {r2, r3}
> 
> I checked that GCC 4.6.3 does not produce such error(s) with the same
> eCos config.
> 
> So, if someone build applications with '-mthumb' then in theory he can
> catch the GCC bug #49641 if it was used arm-eabi GCC 4.6.{1,2}.
> 
> Thus, IMHO, we have to switch to GCC-4.6.3 code base.

This is enough for me. +1
Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #30 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-10 23:46:14 GMT ---
Another serious bug in GCC 4.6.2

I have started playing with Cortex-M4 Floating Point Unit and found out that
conversion between float and double doesn't work when hardware floating point
is on: -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16

For instance:

{
     double dbl;
     float flo;

    //.....
     dbl = flo;
    // dbl is rubish
}

It is due to wrong helper library and seem to be the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835

I tried GCC 4.6.3 and it seems to work. I'll do some more tests but IMO we
should start considering of replacing current 4.6.2-20120125 test release with
something newer, possibly 4.6.3. Building of 4.6.3, as noted by Sergei
(comment# 25), is quite straight-forward - I just applied the 4.6.2 patches.

Of course, until this is resolved nothing can stop us from hunting warnings
with current test release.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #31 from John Dallaway <john@dallaway.org.uk> 2012-03-13 14:30:55 GMT ---
(In reply to comment #30)

> I tried GCC 4.6.3 and it seems to work. I'll do some more tests but IMO we
> should start considering of replacing current 4.6.2-20120125 test release with
> something newer, possibly 4.6.3. Building of 4.6.3, as noted by Sergei
> (comment# 25), is quite straight-forward - I just applied the 4.6.2 patches.
> 
> Of course, until this is resolved nothing can stop us from hunting warnings
> with current test release.

I am quite busy this week but might find some time to build a new test release
based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
'g' packet reply issue or continue with the current "set tdesc" workaround
until the merge of his patch with other changes has occurred and we can apply
something which reflects the upstream changes. Comments?

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #32 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-13 16:20:04 GMT ---
(In reply to comment #31)
> 
> I am quite busy this week but might find some time to build a new test release
> based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> 'g' packet reply issue or continue with the current "set tdesc" workaround
> until the merge of his patch with other changes has occurred and we can apply
> something which reflects the upstream changes. Comments?

There's still a bit of discussion (due to uncertainty on my part in fact), but
you can be pretty confident something similar to the following (post-merge)
patch will be applied:
http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html

Or you can leave it out if you don't intend these tools to be the final tools.
But IMO we shouldn't ship a GDB without something akin to this fix being
included.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-15 15:44:09 GMT ---
It took some time but now I am able to run kernel fptest.c (with just enough
Cortex-M FPU arch HAL). I tweaked the test so it works with floats rather than
doubles, but also has a double in order to enforce the case from comment 30.
Here's the printout:

INFO:<Run fptest in cyg_start>
INFO:<cyg_start run done>
PASS:<OK>
EXIT:<FP Test done>

(In reply to comment #32)
> (In reply to comment #31)
> > 
> > I am quite busy this week but might find some time to build a new test release
> > based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> > 'g' packet reply issue or continue with the current "set tdesc" workaround
> > until the merge of his patch with other changes has occurred and we can apply
> > something which reflects the upstream changes. Comments?

I'm not a GDB expert but it is likely that I'll have to implement the target
part of support for VFP registers. I'll have a lot of questions then, but for
the time being is this: would it be possible to also provide similar workaround
(xml file) for VFP?

> 
> There's still a bit of discussion (due to uncertainty on my part in fact), but
> you can be pretty confident something similar to the following (post-merge)
> patch will be applied:
> http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html
> 
> Or you can leave it out if you don't intend these tools to be the final tools.

My answer is I don't know, but it is very likely that we'll have another
iteration(s) with GDB, at least in order to adopt VFP registers.

> But IMO we shouldn't ship a GDB without something akin to this fix being
> included.
> 

To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
for the time being to go with GDB as-is (or with work-around) and gain some
time for Jifl's patch + VFP support.

If we agree, I hope John can produce test release before his trip to USA.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #34 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-15 21:42:45 GMT ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > 
> > > I am quite busy this week but might find some time to build a new test release
> > > based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> > > 'g' packet reply issue or continue with the current "set tdesc" workaround
> > > until the merge of his patch with other changes has occurred and we can apply
> > > something which reflects the upstream changes. Comments?
> 
> I'm not a GDB expert but it is likely that I'll have to implement the target
> part of support for VFP registers. I'll have a lot of questions then, but for
> the time being is this: would it be possible to also provide similar workaround
> (xml file) for VFP?

You won't need it. You shouldn't need a target description file when using VFP.
You just have to make sure you have made the necessary changes in the stub so
that when VFP is used, it sends the registers in the format GDB expects. i.e.:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/features/arm-with-vfpv3.c?rev=1&content-type=text/x-cvsweb-markup&cvsroot=src

Bear in mind, the purpose of various changes (including the most recent) I've
made to GDB and Cortex-M was trying to give GDB the smarts to identify what to
do based on the executable you are debugging. Indeed, if you are using VFP,
then GDB should infer that from the executable automatically. The user should
have to do nothing special.

> > There's still a bit of discussion (due to uncertainty on my part in fact), but
> > you can be pretty confident something similar to the following (post-merge)
> > patch will be applied:
> > http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html
> > 
> > Or you can leave it out if you don't intend these tools to be the final tools.
> 
> My answer is I don't know, but it is very likely that we'll have another
> iteration(s) with GDB, at least in order to adopt VFP registers.

I wouldn't have thought there would be a problem with GDB after my patch,
unless there is a problem with GDB's support for VFP on Cortex-M4 more
generally - not specific to eCos.

> > But IMO we shouldn't ship a GDB without something akin to this fix being
> > included.
> > 
> 
> To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> for the time being to go with GDB as-is (or with work-around) and gain some
> time for Jifl's patch + VFP support.

The version of the patch referenced from comment 32 is what I have now
committed to GDB. So that is now official.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-16 08:35:55 GMT ---
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> > > (In reply to comment #31)
> > > > 

[snip]

> You just have to make sure you have made the necessary changes in the stub so
> that when VFP is used, it sends the registers in the format GDB expects. i.e.:
> 

I am going to open a bug on Cortex-M FPU architecture and put my questions
there.

[snip]

> > To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> > for the time being to go with GDB as-is (or with work-around) and gain some
> > time for Jifl's patch + VFP support.
> 
> The version of the patch referenced from comment 32 is what I have now
> committed to GDB. So that is now official.

This gives us a new prospective. I would try immediately. Two questions that
will save me some time:

     - Which GDB: version/backport, snapshot or take it from CVS?
     - Is it still necessary have to apply the eCos back-trace patch
(attachment 1540)?

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-16 16:08:58 GMT ---
(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #33)
> > > (In reply to comment #32)
> > > > (In reply to comment #31)
> > > > > 
> 
> [snip]
> 
> > You just have to make sure you have made the necessary changes in the stub so
> > that when VFP is used, it sends the registers in the format GDB expects. i.e.:
> > 
> 
> I am going to open a bug on Cortex-M FPU architecture and put my questions
> there.
> 
> [snip]
> 
> > > To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> > > for the time being to go with GDB as-is (or with work-around) and gain some
> > > time for Jifl's patch + VFP support.
> > 
> > The version of the patch referenced from comment 32 is what I have now
> > committed to GDB. So that is now official.
> 
> This gives us a new prospective. I would try immediately. Two questions that
> will save me some time:
> 
>      - Which GDB: version/backport, snapshot or take it from CVS?
>      - Is it still necessary have to apply the eCos back-trace patch
> (attachment 1540 [details])?
> 

I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

1. Building was breaking for the file /gdb/gnu-v3-abi.c with error "variable
might be used uninitialized". It builds after following workaround:

@@ -870,7 +870,7 @@
   for (i = 0; i <= max_voffset; ++i)
     {
       struct value *vfn;
-      CORE_ADDR addr;
+      CORE_ADDR addr = 0; //VAE
       volatile struct gdb_exception ex;

       printf_filtered ("[%d]: ", i);

2. Support for VFP as the one found on Cortex-M4F appears to be missing (from
what I see in gdb/features). Cortex-M4F has vfpv4-sp-d16: VFP version 4, single
precision with 16 d registers. Note: There is vfpv2 that presents 16 d
registers but it is not quite adequate as Cortex-M4F 16 d registers are at the
same time 32 s (single precision) registers.

Considering the said above, my proposal is: At present continue with GDB as-is
and define time-frame (2-4 week) for next milestone that would be either GDB
7.3 with backport of the patch or GDB 7.4 - in both cases with addition of
Cortex-M FPU profile.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #37 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-18 00:41:10 GMT ---
(In reply to comment #36)
> 
> I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

I wouldn't recommend using a random day's snapshot. I'd recommend using a
stable release with the patch applied. Hence having problems like build errors.

> 2. Support for VFP as the one found on Cortex-M4F appears to be missing (from
> what I see in gdb/features). Cortex-M4F has vfpv4-sp-d16: VFP version 4, single
> precision with 16 d registers. Note: There is vfpv2 that presents 16 d
> registers but it is not quite adequate as Cortex-M4F 16 d registers are at the
> same time 32 s (single precision) registers.

The single precision registers are just virtual halves of the double registers.
Look at the use of vfp_pseudos in arm-tdep.c. From what I can see they should
spring into existence automatically as pseudo-regs if there are d registers in
the target description, and no s registers defined (specifically GDB checks
there is no "s0"). So in theory I would expect vfp2 to be a close match.

However in practice it appears that's probably not going to help much. I
thought GDB was indeed meant to be doing the right thing based on what
registers it sees, but it looks like what VFP work there has been in public GDB
has been oriented around native Linux, and so anything VFP-related will not be
available for us. Sigh. In any case, I notice even the VFP support there refers
to cpsr, not xpsr, which is not ideal (even though it's only a name).

So it looks like we need a further patch for GDB to add the Cortex-M4 register
set after all :-/. Otherwise it will make life much for confusing for our
users, and much more awkward for anyone trying to use eCos with Eclipse
(eCosCentric would be all right because we spin our own tools anyway for
eCosPro, so if we needed this support we would just go ahead and add it, but I
don't see why eCos users should be at a disadvantage).

The easiest approach is probably a further extension of the register guessing.

> Considering the said above, my proposal is: At present continue with GDB as-is
> and define time-frame (2-4 week) for next milestone that would be either GDB
> 7.3 with backport of the patch or GDB 7.4 - in both cases with addition of
> Cortex-M FPU profile.

I don't have a way to test what you're doing, but I will attach an untested
patch which I believe should work. This is on top of the earlier patch. Let me
know how you get on with it. Once we're happy the patch works, I can get it
into upstream GDB.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #38 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-18 00:42:44 GMT ---
Created an attachment (id=1647)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1647)
Prospective GDB patch (against GDB trunk) for Cortex-M4F registers

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-18 13:06:07 GMT ---
(In reply to comment #39)
> Created an attachment (id=1648)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1648) [details]
> Prospective GDB patch (against GDB trunk) for Cortex-M4F registers (fixed)
> 
> Revised version of the patch I just attached - I made a silly omission. Ignore
> the previous.

Thank you Jifl.

I'll try this. However, please note that despite having double registers
d0..d15 Cortex-M4F has hardware support only for single precision FP arithmetic
so single precision view of registers (s0..s31 instead of d0..d15) would be
more useful for floating point representation of register contents. Double
precision floating point is actually done in software and does not involve
d0..d15, at least not with GCC. Single precision naturally uses s0..s31 VFP
registers. Below there is a code sample.

void main(void)
{
    volatile float fla, flb, flc;
    volatile double dla, dlb, dlc;

    printf("Enter floats: ");
    scanf("%f %f", &fla, &flb);
    printf("Enter doubles: ");
    scanf ("%lf %lf", &dla, &dlb);

    flc = fla + flb;

    dlc = dla + dlb;

    printf("%f + %f = %f\n", fla, flb, flc);
    printf("%f + %f = %f\n", dla, dlb, dlc);
}

Disassembly gives:

    flc = fla + flb;
1fff0536:    ed9d 7a0b     vldr    s14, [sp, #44]    ; 0x2c
1fff053a:    eddd 7a0c     vldr    s15, [sp, #48]    ; 0x30
1fff053e:    ee77 7a27     vadd.f32    s15, s14, s15

    dlc = dla + dlb;
1fff054a:    e9dd 0104     ldrd    r0, r1, [sp, #16]
1fff054e:    e9dd 2306     ldrd    r2, r3, [sp, #24]
1fff0552:    f007 fa3b     bl    1fff79cc <__adddf3>
1fff0556:    e9cd 0108     strd    r0, r1, [sp, #32]

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #41 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-19 01:50:00 GMT ---
(In reply to comment #40)
> 
> I'll try this. 

Thanks.

> However, please note that despite having double registers
> d0..d15 Cortex-M4F has hardware support only for single precision FP arithmetic
> so single precision view of registers (s0..s31 instead of d0..d15) would be
> more useful for floating point representation of register contents.
> Double
> precision floating point is actually done in software and does not involve
> d0..d15, at least not with GCC.
> Single precision naturally uses s0..s31 VFP
> registers. Below there is a code sample.

Yes I know, but as per comment 37, GDB provides pseudo-regs for the single
precision registers, so you can still see them (if you can't see them after my
patch then I've missed something). It will be alongside the d0..d15 view of the
registers, in line with all other ARM VFP FPUs, and it could be argued that
since http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/BEHJADED.html
shows that you can still load and store doubles, it should still be possible to
have some means of viewing them.

Anyway, GDB has no support for any other model for the single precision
registers. Doing anything else would require quite a few GDB changes for
nothing more than cosmetic gain (the removal of the d0..15 part of the view of
registers in 'info all-reg'). Simply put, the behaviour you are looking for is
not yet possible to arrange in GDB at the moment.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|eCos GNU tools 4.6.2        |eCos GNU tools 4.6.3

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #42 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-30 16:00:55 BST ---
Hi JIfl

(In reply to comment #41)

Now I have enough Cortex-M4F architectural support to do some GDB testing. I
have applied the attachment (id=1648) and it seems to work with following
issues:

1. Remote 'g' packet reply is too long

If I connect to gdb server (RedBoot on Cortex-M4F) prior to submit the elf file
I get the error /Remote 'g' packet reply is too long/:

--- Capture -------
(gdb) target remote 192.168.209.246:9000
Remote debugging using 192.168.209.246:9000
Remote 'g' packet reply is too long:
01550000100000000000000010000000000000000000000000000000000000000000000000000000
00000000000000000000000030ffff77d56d00000255000000000000015500001000000000000000
10000000000000000000000000000000000000000000000000000000000000000000000000000000
30ffff77d56d0000025500000000000100000000d56f0000fdbfffffeff7ffffdbf3efbfc56d0000
f3fdff7f6fe777fdfe6f7ffffceaffffffffffffebf7ff7feffffeffffffefffbfbfff5d98feff77
(gdb)
--- Capture END -------

If I introduce a target file before connection, GDB get's prepared for this
packet and accepts connection.

--- Capture -------

(gdb) file fpinttest.elf 
Reading symbols from
/home/vae/Proekti/pd/sem/rtlinux/posix_lin_ecos/bin/fpinttest.elf...done.
(gdb) target remote 192.168.209.246:9000
Remote debugging using 192.168.209.246:9000
0x00005502 in ?? ()
(gdb) info all-registers 
r0             0x5501    21761
r1             0x10    16
r2             0x0    0
r3             0x10    16
r4             0x0    0
r5             0x0    0
r6             0x0    0
r7             0x0    0
r8             0x0    0
r9             0x0    0
r10            0x0    0
r11            0x0    0
r12            0x0    0
sp             0x77ffff30    0x77ffff30
lr             0x6dd5    28117
pc             0x5502    0x5502
xpsr           0x0    0
d0             3.3951943406806876e-313    (raw 0x0000001000005501)
d1             3.3951932655444357e-313    (raw 0x0000001000000000)
d2             0    (raw 0x0000000000000000)
d3             0    (raw 0x0000000000000000)
d4             0    (raw 0x0000000000000000)
d5             0    (raw 0x0000000000000000)
d6             1.0564842675187554e+270    (raw 0x77ffff3000000000)
d7             4.61788724168779e-310    (raw 0x0000550200006dd5)
d8             8.289046058458095e-317    (raw 0x0000000001000000)
d9             -nan(0xfbffd00006fd5)    (raw 0xffffbffd00006fd5)
d10            -0.99851799011207543    (raw 0xbfeff3dbfffff7ef)
d11            nan(0xffdf300006dc5)    (raw 0x7ffffdf300006dc5)
d12            -1.3797595269860335e+306    (raw 0xff7f6ffefd77e76f)
d13            -nan(0xfffffffffeafc)    (raw 0xffffffffffffeafc)
d14            -nan(0xeffef7ffff7eb)    (raw 0xfffeffef7ffff7eb)
d15            6.1945292423959159e+144    (raw 0x5dffbfbfffefffff)
fpscr          0x77fffe98    2013265560
s0             3.04936559e-41    (raw 0x00005501)
s1             2.24207754e-44    (raw 0x00000010)
s2             0    (raw 0x00000000)
s3             2.24207754e-44    (raw 0x00000010)
s4             0    (raw 0x00000000)
s5             0    (raw 0x00000000)
s6             0    (raw 0x00000000)
s7             0    (raw 0x00000000)
s8             0    (raw 0x00000000)
s9             0    (raw 0x00000000)
---Type <return> to continue, or q <return> to quit---
s10            0    (raw 0x00000000)
s11            0    (raw 0x00000000)
s12            0    (raw 0x00000000)
s13            1.0384465e+34    (raw 0x77ffff30)
s14            3.94003089e-41    (raw 0x00006dd5)
s15            3.04950572e-41    (raw 0x00005502)
s16            2.3509887e-38    (raw 0x01000000)
s17            0    (raw 0x00000000)
s18            4.01177737e-41    (raw 0x00006fd5)
s19            -nan(0x7fbffd)    (raw 0xffffbffd)
s20            -nan(0x7ff7ef)    (raw 0xfffff7ef)
s21            -1.87462938    (raw 0xbfeff3db)
s22            3.93778881e-41    (raw 0x00006dc5)
s23            nan(0x7ffdf3)    (raw 0x7ffffdf3)
s24            -2.05950617e+37    (raw 0xfd77e76f)
s25            -3.39534636e+38    (raw 0xff7f6ffe)
s26            -nan(0x7feafc)    (raw 0xffffeafc)
s27            -nan(0x7fffff)    (raw 0xffffffff)
s28            nan(0x7ff7eb)    (raw 0x7ffff7eb)
s29            -nan(0x7effef)    (raw 0xfffeffef)
s30            -nan(0x6fffff)    (raw 0xffefffff)
s31            2.30358228e+18    (raw 0x5dffbfbf)
(gdb) 

--- Capture END -------

This is probably not a problem when using gdb from command line, but it is with
Eclipse.


2. Potential eCos/RedBoot issues

Since register numbers are not consecutive there may be issue with some stub
eCos/Redboot functions: For instance stub_format_registers() requires
consecutive numbers.

Ilija.

P.S. I am going to open bug(s) on Cortex_M4F architectural support but for GDB
matters perhaps we continue in Bug 1001524.

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #43 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-30 16:20:19 BST ---
Ok, I'll reply in bug 1001524

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |1001524

--- Comment #44 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-26 16:33:00 BST ---
As per http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524#c22 the GDB
changes for Cortex-M4F have been finalised, so we should be good to go with
another rebuild of GDB. This bug initially mentioned GDB 7.3.1, but since GDB
7.4 is out (as of 2012-01-24), presumably it's best to use that now.

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #45 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-27 10:20:04 BST ---
(In reply to comment #44)
> As per http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524#c22 the GDB
> changes for Cortex-M4F have been finalised, so we should be good to go with

Thanks.

> another rebuild of GDB. This bug initially mentioned GDB 7.3.1, but since GDB
> 7.4 is out (as of 2012-01-24), presumably it's best to use that now.

I tried 7.4.50.20120427 snapshot and the patch is already there. Probably we
could start with that or wait a bit for weekly snapshot.

Just for information if you could provide, do we have a prospective for GDB
7.4.2? Time frame?

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #46 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-27 15:36:51 BST ---
(In reply to comment #45)
> (In reply to comment #44)
> > another rebuild of GDB. This bug initially mentioned GDB 7.3.1, but since GDB
> > 7.4 is out (as of 2012-01-24), presumably it's best to use that now.
> 
> I tried 7.4.50.20120427 snapshot and the patch is already there. Probably we
> could start with that or wait a bit for weekly snapshot.

Maybe, although there are risks in using a snapshot from a random date. I had
been thinking more of just applying these patches to a stable release,
presumably 7.4.1. They aren't substantial patches really.

> Just for information if you could provide, do we have a prospective for GDB
> 7.4.2? Time frame?

If there is a 7.4.2 it would be very unlikely to contain these patches. It
would be a bugfix release only from the 7.4 branch - I only applied my patches
to the trunk and would need separate approval from the release manager to apply
them to the 7.4 branch (which I doubt I would get). We would need to wait for a
GDB 7.5, and that won't be happening any time soon. The most important thing
for us getting them committed is so that we would have certainty that a future
GDB 7.5 (and later) would continue to work.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #47 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-27 16:24:53 BST ---
(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > another rebuild of GDB. This bug initially mentioned GDB 7.3.1, but since GDB
> > > 7.4 is out (as of 2012-01-24), presumably it's best to use that now.
> > 
> > I tried 7.4.50.20120427 snapshot and the patch is already there. Probably we
> > could start with that or wait a bit for weekly snapshot.
> 
> Maybe, although there are risks in using a snapshot from a random date. I had
> been thinking more of just applying these patches to a stable release,
> presumably 7.4.1. They aren't substantial patches really.
> 

I'm about to start testing, but... see below

> > Just for information if you could provide, do we have a prospective for GDB
> > 7.4.2? Time frame?
> 
> If there is a 7.4.2 it would be very unlikely to contain these patches. It
> would be a bugfix release only from the 7.4 branch - I only applied my patches
> to the trunk and would need separate approval from the release manager to apply
> them to the 7.4 branch (which I doubt I would get). We would need to wait for a
> GDB 7.5, and that won't be happening any time soon. The most important thing
> for us getting them committed is so that we would have certainty that a future
> GDB 7.5 (and later) would continue to work.
> 

I'm afraid waiting for 7.5 would be too long.

I wander that provided that we patch 7.4.1 and we test it and it works for us,
could then we consider it our release? It will bear mark "eCos GNU tools 4.6.3"
so there will be no confuse with "standard" GDB 7.4.1.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #48 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-27 17:16:04 BST ---
(In reply to comment #47)
> (In reply to comment #46)
> > If there is a 7.4.2 it would be very unlikely to contain these patches. It
> > would be a bugfix release only from the 7.4 branch - I only applied my patches
> > to the trunk and would need separate approval from the release manager to apply
> > them to the 7.4 branch (which I doubt I would get). We would need to wait for a
> > GDB 7.5, and that won't be happening any time soon. The most important thing
> > for us getting them committed is so that we would have certainty that a future
> > GDB 7.5 (and later) would continue to work.
> 
> I'm afraid waiting for 7.5 would be too long.

Yes, that's what I was trying to say.

> I wander that provided that we patch 7.4.1 and we test it and it works for us,
> could then we consider it our release? It will bear mark "eCos GNU tools 4.6.3"
> so there will be no confuse with "standard" GDB 7.4.1.

Yes, which is why I wrote: "I had been thinking more of just applying these
patches to a stable release, presumably 7.4.1."

We will already be applying my other GDB patches as well (for avoiding
backtrace loops, as well as the workaround for NULL frames), so it wouldn't be
a standard GDB anyway.

That prompted me to have a look at the build scripts you attached to this bug
and I noticed a little thing... You should also configure all the tools with:
 --with-bugurl=http://bugs.ecos.sourceware.org/

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #49 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-25 21:31:46 BST ---
Created an attachment (id=1766)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1766)
GDB 7.4.1 M-profile and VFPv4-SP-d16 support 20120524

I apologize for the delay, I had to do other things that broke and put the
Cortex GDB stub in a stale for a while. Now it's on track again so I did the
backport of Jifl's patches to GDB 7.4.1 (ref
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524#c22) and it seems to
work fine. For convenience I have prepared a unified patch against clean GDB
7.4.1 (Attached).

This patch should be applied to GDB in addition to Attachment 1540.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1535|0                           |1
        is obsolete|                            |

--- Comment #50 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-25 21:38:40 BST ---
Created an attachment (id=1767)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1767)
eCos Multilib configuration 20120524

The attached patch adds Cortex-M9 to the multilib matches. It shall not
generate additional libraries but will add Cortex-M9 to match Thumb2 libs.
Should be applied instead of the obsoleted attachment 1535.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #51 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-26 03:50:35 BST ---
(In reply to comment #50)
> Created an attachment (id=1767)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1767) [details]
> eCos Multilib configuration 20120524
> 
> The attached patch adds Cortex-M9 to the multilib matches. It shall not
> generate additional libraries but will add Cortex-M9 to match Thumb2 libs.

You mean Cortex-A9. Presumably this is just for completeness rather than you
working on Cortex-A support?

Do we really need -mfloat-abi=hard? Do we have anything that uses it?

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #52 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-26 07:44:41 BST ---
(In reply to comment #51)
> (In reply to comment #50)
> > Created an attachment (id=1767)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1767) [details]
[details]
> > eCos Multilib configuration 20120524
> > 
> > The attached patch adds Cortex-M9 to the multilib matches. It shall not
> > generate additional libraries but will add Cortex-M9 to match Thumb2 libs.
> 
> You mean Cortex-A9. Presumably this is just for completeness rather than you
> working on Cortex-A support?

You're correct, sorry, it is Cortex-A9 indeed. Yes, Cortex-A9 is merely added
to MULTILIB-MATCHES list. Cortex-A support is not in my focus, but I have been
asked by one considering it. Probably it is not critical to have A9 in, but
since it is a trivial change and we are going to have a new test release
anyway, I added it.

> 
> Do we really need -mfloat-abi=hard? Do we have anything that uses it?

-mfloat-abi=hard goes along with -mfpu=fpv4-sp-d16. Both flags have to be
specified. The use case, Cortex-M4 arch for floating point is almost ready, I
am doing final testing and my aim is to put it on Bugzilla within few days.

Note: Addition of Cortex-A9 doesn't include multilib for it's FPU.

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

[Bug 1001468] eCos GNU tools 4.6.3

[bugzilla-daemon]

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

--- Comment #53 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-26 16:36:57 BST ---
(In reply to comment #52)
> (In reply to comment #51)
> > 
> > Do we really need -mfloat-abi=hard? Do we have anything that uses it?
> 
> -mfloat-abi=hard goes along with -mfpu=fpv4-sp-d16. Both flags have to be
> specified. The use case, Cortex-M4 arch for floating point is almost ready, I
> am doing final testing and my aim is to put it on Bugzilla within few days.

Ah ok, I assume you've designed the MULTILIB_EXCEPTIONS in such a way that
-mfloat-abi=hard is only there at the same time as -mfpu=fpv4-sp-d16 and
vice-versa. Since you'll have built it then of course -print-multi-lib will
verify this easily enough if you haven't already.

Thanks!
Jifl

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

[Bug 1001468] New: eCos GNU tools 4.6.2

[bugzilla-daemon]

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

           Summary: eCos GNU tools 4.6.2
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: Other
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org
             Group: eCos
             Class: Advice Request


eCos GNU tools 4.6.2

Components:
    GCC 4.6.2 (needs patches for eCos, - Multilib, etc)
        gcc-core
        gcc-g++
    Binutils 2.22
    GDB 7.3.1 (needs eCos back-trace patch)

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:54:45 GMT ---
Created an attachment (id=1535)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1535)
eCos Multilib configuration 20110125

This file is separated in it's own file in order to facilitate eventual changes
to multilib configuration.

New since ver 4.3.2

Added library configuration for FPv4-SP-D16-M, FPU found on Cortex-M4F cores.
--- /tmp/multilib_4.3.2.out    2012-01-28 18:53:50.744015282 +0100
+++ /tmp/multilib_4.6.2.out    2012-01-28 18:53:50.748015282 +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

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:57:37 GMT ---
Created an attachment (id=1536)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1536)
ARM GCC patches

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 17:58:55 GMT ---
Created an attachment (id=1537)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1537)
General GCC configuration patches 20110125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:00:00 GMT ---
Created an attachment (id=1538)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1538)
libgcc patches 20110125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:01:21 GMT ---
Created an attachment (id=1539)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1539)
libstdc++-v3 patches 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:02:25 GMT ---
Created an attachment (id=1540)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1540)
gdb 7.3.1. back-trace patch 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1536|ARM GCC patches             |ARM GCC patches 20120125
        description|                            |

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1535|eCos Multilib configuration |eCos Multilib configuration
        description|20110125                    |20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1538|libgcc patches 20110125     |libgcc patches 20120125
        description|                            |

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1537|General GCC configuration   |General GCC configuration
        description|patches 20110125            |patches 20120125

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2012-01-28 18:13:26 GMT ---
Created an attachment (id=1541)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1541)
Build scripts 20120125

Here are my building scripts for reference.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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.

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-01-31 20:55:43 GMT ---
In comment #8 read

  a fix in 'config.host'

instead of

  a fix in 'config/host'

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 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
them.

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

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. 

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #11 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-03 18:54:25 GMT ---
(In reply to comment #10)

Hi Ilija,

[snip]

> Generally I find are 3 categories of patches (speaking about GCC):
>    - Bug fixes/workarounds: (such as LDRD). They are obsolete so I
>    have omitted them.

Good to know. Thank you for dive in.

>    - eCos related changes other than multilib: I assume we still want
>    them and I have applied them verbatim.

It looks like that. It seemed to me that they knew what they done
(fixed). They are strong experts.

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

May be for now, but, (IMHO) all tweaks for any architecture must be
accumulated *at the end* in a final gcc-4.6.2-<arch>.patch. However, it
is not issue for me if you do prefer small deltas to apply.

> 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 think this is no problem. A matter of taste. But I would combine all
common things (for c/c++) in one gcc-4.6.2.patch.

[snip]

> > 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-* :-)

[snip]

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

Fortunately, gcc stores its configure options:

  % <target>-gcc -v

Thus, you can use (for start) configure options for GCC 4.3.2 from
eCosCentric. As you can see eCosCentric built and some cross tools
(libraries) as gmp, mpfr; it seems to me it must be used for the GCC
4.6.2 build too to prevent the host's dependencies and may be it will
need more (or less) libraries (need to investigate).

Ilija, I will try to build new toolchain for i386 architecture. It's
easier to build (less time to wait for :-) and test for me and then I
will share the got configure options and any "finds" for the build
here.

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.

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-04 19:39:38 GMT ---
(In reply to comment #11)

> Thus, you can use (for start) configure options for GCC 4.3.2 from
> eCosCentric. As you can see eCosCentric built and some cross tools
> (libraries) as gmp, mpfr; it seems to me it must be used for the GCC
> 4.6.2 build too to prevent the host's dependencies and may be it will
> need more (or less) libraries (need to investigate).

It was much easier to find dependences than I thought. Required items to
build GCC 4.6.2 are described in GCC documentation :-)

 gcc-4.6.2/INSTALL/prerequisites.html

It seems to me GCC build requires GMP, MPFR, MPC libraries (Necessary to
Build GCC). So, these libraries look like SHOULD requirements.  And PPL,
CLooG (IMHO) look like COULD requirements (Necessary to build GCC with
the Graphite loop optimizations), and may be even WON'T requirement for
eCos.

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.

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #13 from John Dallaway <john@dallaway.org.uk> 2012-02-06 09:15:56 GMT ---
I now have a portable build of the arm-eabi toolchain for i686-pc-linux-gnu
hosts, but the build for i686-pc-cygwin hosts is proving to be a problem. There
is an issue with building libiberty with my Cygwin installation. I would prefer
to release the initial test toolchain for both hosts together if possible. I'm
checking the mailing lists...

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 16:23:05 GMT ---
(In reply to comment #11)
> Ilija, I will try to build new toolchain for i386 architecture. It's
> easier to build (less time to wait for :-) and test for me and then I will
> share the got configure options and any "finds" for the build here.

(In reply to comment #12)
> It seems to me GCC build requires GMP, MPFR, MPC libraries (Necessary to
> Build GCC). So, these libraries look like SHOULD requirements.  And PPL,
> CLooG (IMHO) look like COULD requirements (Necessary to build GCC with the
> Graphite loop optimizations), and may be even WON'T requirement for eCos.

For now I stick at such an option set for 'i386-elf' target:

  % i386-elf-gcc -v
  Using built-in specs.
  COLLECT_GCC=i386-elf-gcc
 
COLLECT_LTO_WRAPPER=/home/test/gnutools/i386-elf/libexec/gcc/i386-elf/4.6.2/lto-wrapper
  Target: i386-elf
  Configured with: /home/test/build/gcc-4.6.2/configure -v
--with-pkgversion='eCos GNU tools 4.6.2-1'
--with-bugurl=http://bugs.ecos.sourceware.org --enable-languages=c,c++
--prefix=/home/test/gnutools/i386-elf --enable-threads --with-gnu-as
--with-gnu-ld --with-newlib --with-mpfr=/home/test/gnutools/tools
--with-gmp=/home/test/gnutools/tools --with-mpc=/home/test/gnutools/tools
--disable-__cxa_atexit --disable-hosted-libstdcxx --disable-decimal-float
--disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath
--disable-multilib --disable-nls --disable-shared --target=i386-elf
  Thread model: single
  gcc version 4.6.2 (eCos GNU tools 4.6.2-1)

NOTES

1) A bit modified patches for 4.3.2 from eCosCentric were applied for 4.6.2
sources;

2) HOSTCC was i486-linux-gnu-gcc.

Q: Do we interested in the builds (tests) pass itself on x86_64 hosts?

Well, I liked that new compilers do produce no new warnings, but

  [-Wunused-but-set-variable]

So, we have a straightforward solution to fix all them :-)  So far, I tested
only builds for eCos default template +FILEIO +USTL. New GDB has not been
tested yet (I think this can take the next weekend).

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 20:51:29 GMT ---
(In reply to comment #13)
> I now have a portable build of the arm-eabi toolchain for
> i686-pc-linux-gnu hosts, but the build for i686-pc-cygwin hosts is
> proving to be a problem. There is an issue with building libiberty
> with my Cygwin installation. I would prefer to release the initial
> test toolchain for both hosts together if possible. I'm checking the
> mailing lists...

Hi John,

If the issue is building *GCC* libiberty, you would try to use this
one from Binutils as I found other do it

http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html
http://www.linuxquestions.org/questions/linux-software-2/compiling-gcc-4-5-2-without-libiberty-917624/

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.

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #16 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-11 21:53:30 GMT ---
(In reply to comment #15)
> > I now have a portable build of the arm-eabi toolchain for
> > i686-pc-linux-gnu hosts, but the build for i686-pc-cygwin hosts is
> > proving to be a problem. There is an issue with building libiberty
> > with my Cygwin installation. I would prefer to release the initial
> > test toolchain for both hosts together if possible. I'm checking the
> > mailing lists...
> 
> If the issue is building *GCC* libiberty, you would try to use this
> one from Binutils as I found other do it
> 
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html
> http://www.linuxquestions.org/questions/linux-software-2/compiling-gcc-4-5-2
> -without-libiberty-917624/

Yet another story (in Japanese) [Excuse my posts if you read all already]

  http://www5.ocn.ne.jp/~tane/prog/win/howtobuildtools.html

NOTE: As for me Google Translate translated the page (URL -> autodetect
lang) just fine.

There is described how Tane built the same cross tools (2.22+4.6.2) for
PowerPC target on *Cygwin* host there. There are all configure options
for that and Tane also points on LFS project. Though, I read Cross-LFS
"books" (cross-lfs.org) + looked at some SlackBuild scripts when worked
on my build script.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #18 from John Dallaway <john@dallaway.org.uk> 2012-02-14 22:07:20 GMT ---
(In reply to comment #17)

> I am concerned about some warnings on configure libstdc++ libraries ...
> 
>   checking for atomic builtins for bool... no
>   checking for atomic builtins for short... no
>   checking for atomic builtins for int... no
>   checking for atomic builtins for long long... no
>   configure: WARNING: No native atomic operations are provided for this
> platform.
>   configure: WARNING: They cannot be faked when thread support is disabled.
>   configure: WARNING: Thread-safety of certain classes is not guaranteed.
> 
> Have you seen these warnings? If you have not, what was your score

We build only libsupc++ from the libstdc++-v3 package. libsupc++ provides 'new'
and 'delete' and these will use the eCos memory allocator.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #20 from John Dallaway <john@dallaway.org.uk> 2012-02-24 12:28:31 GMT ---
(In reply to comment #19)

> This weekend I tested a bit new distributed binaries for arm-eabi and
> also the built toolchains from sources for x86_64 and i686 Linux hosts.

Sergei, thank you for the testing with arm-eabi target. Do you think it would
be useful to generate a similar "test release" for i386-elf target? The eCos
GCC patch for i386 looks like it would be easy to migrate from GCC 4.3.2 to GCC
4.6.2.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #21 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-24 12:48:06 GMT ---
(In reply to comment #20)
> (In reply to comment #19)
> 
> > This weekend I tested a bit new distributed binaries for arm-eabi
> > and also the built toolchains from sources for x86_64 and i686 Linux
> > hosts.
> 
> Sergei, thank you for the testing with arm-eabi target. Do you think
> it would be useful to generate a similar "test release" for i386-elf
> target? The eCos GCC patch for i386 looks like it would be easy to
> migrate from GCC 4.3.2 to GCC 4.6.2.

I have built i386-elf toolchain, but not tested it yet. As I used the
latest mpfr/mpc/gmp,  I shall rebuild the tools with your set of the
libraries, and then I will test got eCos executables on Qemu. I hope I
will finish testing this weekend.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #22 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-26 16:28:30 GMT ---
(In reply to comment #21)
> I have built i386-elf toolchain, but not tested it yet. As I used the
> latest mpfr/mpc/gmp,  I shall rebuild the tools with your set of the
> libraries, and then I will test got eCos executables on Qemu. I hope I
> will finish testing this weekend.

Go flop. The first issue is a built RedBoot (4.6.2) could not assist to
run built eCos tests (4.6.2) under GDB (7.3.1). I have no ideas what was
wrong with that as the same RedBoot sources are built with (GCC-4.3.2)
provide GDB support for new eCos tests (built with GCC-4.6.2) in GDB
7.3.1, and the second issue is that the build tests (with GDB-4.6.2) had
.text segments more bloat (1.1 ~ 1.2) than the same builds are built
with GCC-4.3.2. Though one patch was applied to config/i386/i386elf.h

  ---
   gcc-4.6.2/gcc/config/i386/i386elf.h |    4 ----
   1 file changed, 4 deletions(-)

  --- a/gcc-4.6.2/gcc/config/i386/i386elf.h
  +++ b/gcc-4.6.2/gcc/config/i386/i386elf.h
  @@ -20,10 +20,6 @@
   along with GCC; see the file COPYING3.  If not see
   <http://www.gnu.org/licenses/>.  */

  -/* Use stabs instead of DWARF debug format.  */
  -#undef  PREFERRED_DEBUGGING_TYPE
  -#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG
  -
   #define TARGET_VERSION fprintf (stderr, " (i386 bare ELF target)");

   /* The ELF ABI for the i386 says that records and unions are returned

It seems to me that I cannot propose to s/4.3.2/4.6.2/ for i386 :-( BTW,
mpfr/mpc/gmp versions were not an issue (I had the same results with the
newest libraries and with stable ones).

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #23 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-26 16:49:12 GMT ---
(In reply to comment #22)
> 7.3.1, and the second issue is that the build tests (with GDB-4.6.2) had
                                                            ^^^^^^^^^
Should read                                                 GCC-4.6.2

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #24 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-28 14:03:54 GMT ---
(In reply to comment #22)
> Go flop. The first issue is a built RedBoot (4.6.2) could not assist
> to run built eCos tests (4.6.2) under GDB (7.3.1). I have no ideas
> what was wrong with that as the same RedBoot sources are built with
> (GCC-4.3.2) provide GDB support for new eCos tests (built with
> GCC-4.6.2) in GDB

[snip]

>From my tests RedBoot+GDB on Qemu, the builds of RedBoot for i386 with
default eCos CFLAGS (-g -O2) are "broken" (I got spurious SIGINT after
any diagnostic output in GDB), but, I found that all *not optimized*
RedBoot builds work without such an issue.  Thus, I do not know can I
trust that GCC 4.6.2 build for i386-elf target with that minimal patch.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-02 16:19:22 GMT ---
2012/03/01 GCC 4.6.3 released (http://sourceware.org/gcc/)

As they said GCC 4.6.3 is a bug-fix release for GCC 4.6.2.

I looked at its PR list

 
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3

Well, in main I search for /arm bug-fix reports. My concern is a bug

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641

This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
patch to our new arm-eabi toolchain (4.6.2 based)? What is your opinion? 

FYI 

Good news that I did not meet such gas warnings when I tested GCC 4.6.2
on my board, bad ones that it is possible to get it for other targets,
or ARM7 (armv4) cpus.

I just s/4.6.2/4.6.3/ for my build script and it was possible to build
arm-eabi toolchain (4.6.3). There were no hunks/fails for used patches.
However, I have not tested yet new toolchain on real hardware.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #26 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-03 13:47:31 GMT ---
(In reply to comment #25)
> 2012/03/01 GCC 4.6.3 released (http://sourceware.org/gcc/)
> 
> As they said GCC 4.6.3 is a bug-fix release for GCC 4.6.2.
> 
> I looked at its PR list
> 
>  
> http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3
> 
> Well, in main I search for /arm bug-fix reports. My concern is a bug
> 
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
> 
> This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
> patch to our new arm-eabi toolchain (4.6.2 based)? What is your opinion? 

If the bug is so severe that we must have a fix, considering that we're just
beginning with 4.6, I would consider 4.6.3 rather than a patch.

Otherwise there will be 4.6.minors in future an we can't follow them all.

> 
> FYI 
> 
> Good news that I did not meet such gas warnings when I tested GCC 4.6.2
> on my board, bad ones that it is possible to get it for other targets,
> or ARM7 (armv4) cpus.
> 
> I just s/4.6.2/4.6.3/ for my build script and it was possible to build
> arm-eabi toolchain (4.6.3). There were no hunks/fails for used patches.

Probably the same patches will be applicable without hunk-fails to any
4.6.minor. FYI they stem back from 4.6.0.


> However, I have not tested yet new toolchain on real hardware.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #27 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-03 14:30:11 GMT ---
(In reply to comment #26)
> > Well, in main I search for /arm bug-fix reports. My concern is a bug
> > 
> >   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
> > 
> > This bug exists (not fixed) in GCC 4.6.2. Should we apply a proposal
> > patch to our new arm-eabi toolchain (4.6.2 based)? What is your
> > opinion? 
> 
> If the bug is so severe that we must have a fix, considering that
> we're just beginning with 4.6, I would consider 4.6.3 rather than a
> patch.

Agreed. But if that will be really needed. I would trust the eCosCentric
test results for ARM7 target.

> Otherwise there will be 4.6.minors in future an we can't follow them
> all.

It's clear. I did not suggest to follow all next 4.6 derivatives.

> > Good news that I did not meet such gas warnings when I tested GCC
> > 4.6.2 on my board, bad ones that it is possible to get it for other
> > targets, or ARM7 (armv4) cpus.
> > 
> > I just s/4.6.2/4.6.3/ for my build script and it was possible to
> > build arm-eabi toolchain (4.6.3). There were no hunks/fails for used
> > patches.
> 
> Probably the same patches will be applicable without hunk-fails to any
> 4.6.minor. FYI they stem back from 4.6.0.

Good to know.

> > However, I have not tested yet new toolchain on real hardware.

Today I tested a bit and GCC 4.6.3 based build (just for case)
http://ecos.sourceware.org/ml/ecos-devel/2012-03/msg00002.html

And as I told I had no problems with the contributed toolchain too,
though, my test "farm" is a very little farm (1-board stall), so, I
decided to point on that bug-fix here.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #28 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-03 19:46:17 GMT ---
At the end I found that bug 49641.  I missed it, because STMIA is THUMB
instruction :-) and I never force such option:

  cdl_option CYGHWR_THUMB {
      user_value 1
  };

Well, is unreal config for me, but:

    CC    ip_input.c
  /tmp/cceuQCd7.s: Assembler messages:
  /tmp/cceuQCd7.s:834: Warning: value stored for r3 is UNKNOWN

disassemble output with objdump:

  /tmp/t/net/bsd_tcpip/current/src/sys/netinet/net_bsd_tcpip_ip_icmp.o:
     6:    c30c          stmia    r3!, {r2, r3}

I checked that GCC 4.6.3 does not produce such error(s) with the same
eCos config.

So, if someone build applications with '-mthumb' then in theory he can
catch the GCC bug #49641 if it was used arm-eabi GCC 4.6.{1,2}.

Thus, IMHO, we have to switch to GCC-4.6.3 code base.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #29 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-03 21:17:31 GMT ---
(In reply to comment #28)
> At the end I found that bug 49641.  I missed it, because STMIA is THUMB
> instruction :-) and I never force such option:
> 
>   cdl_option CYGHWR_THUMB {
>       user_value 1
>   };
> 
> Well, is unreal config for me, but:
> 
>     CC    ip_input.c
>   /tmp/cceuQCd7.s: Assembler messages:
>   /tmp/cceuQCd7.s:834: Warning: value stored for r3 is UNKNOWN
> 
> disassemble output with objdump:
> 
>   /tmp/t/net/bsd_tcpip/current/src/sys/netinet/net_bsd_tcpip_ip_icmp.o:
>      6:    c30c          stmia    r3!, {r2, r3}
> 
> I checked that GCC 4.6.3 does not produce such error(s) with the same
> eCos config.
> 
> So, if someone build applications with '-mthumb' then in theory he can
> catch the GCC bug #49641 if it was used arm-eabi GCC 4.6.{1,2}.
> 
> Thus, IMHO, we have to switch to GCC-4.6.3 code base.

This is enough for me. +1
Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #30 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-10 23:46:14 GMT ---
Another serious bug in GCC 4.6.2

I have started playing with Cortex-M4 Floating Point Unit and found out that
conversion between float and double doesn't work when hardware floating point
is on: -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16

For instance:

{
     double dbl;
     float flo;

    //.....
     dbl = flo;
    // dbl is rubish
}

It is due to wrong helper library and seem to be the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835

I tried GCC 4.6.3 and it seems to work. I'll do some more tests but IMO we
should start considering of replacing current 4.6.2-20120125 test release with
something newer, possibly 4.6.3. Building of 4.6.3, as noted by Sergei
(comment# 25), is quite straight-forward - I just applied the 4.6.2 patches.

Of course, until this is resolved nothing can stop us from hunting warnings
with current test release.

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #31 from John Dallaway <john@dallaway.org.uk> 2012-03-13 14:30:55 GMT ---
(In reply to comment #30)

> I tried GCC 4.6.3 and it seems to work. I'll do some more tests but IMO we
> should start considering of replacing current 4.6.2-20120125 test release with
> something newer, possibly 4.6.3. Building of 4.6.3, as noted by Sergei
> (comment# 25), is quite straight-forward - I just applied the 4.6.2 patches.
> 
> Of course, until this is resolved nothing can stop us from hunting warnings
> with current test release.

I am quite busy this week but might find some time to build a new test release
based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
'g' packet reply issue or continue with the current "set tdesc" workaround
until the merge of his patch with other changes has occurred and we can apply
something which reflects the upstream changes. Comments?

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #32 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-13 16:20:04 GMT ---
(In reply to comment #31)
> 
> I am quite busy this week but might find some time to build a new test release
> based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> 'g' packet reply issue or continue with the current "set tdesc" workaround
> until the merge of his patch with other changes has occurred and we can apply
> something which reflects the upstream changes. Comments?

There's still a bit of discussion (due to uncertainty on my part in fact), but
you can be pretty confident something similar to the following (post-merge)
patch will be applied:
http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html

Or you can leave it out if you don't intend these tools to be the final tools.
But IMO we shouldn't ship a GDB without something akin to this fix being
included.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-15 15:44:09 GMT ---
It took some time but now I am able to run kernel fptest.c (with just enough
Cortex-M FPU arch HAL). I tweaked the test so it works with floats rather than
doubles, but also has a double in order to enforce the case from comment 30.
Here's the printout:

INFO:<Run fptest in cyg_start>
INFO:<cyg_start run done>
PASS:<OK>
EXIT:<FP Test done>

(In reply to comment #32)
> (In reply to comment #31)
> > 
> > I am quite busy this week but might find some time to build a new test release
> > based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> > 'g' packet reply issue or continue with the current "set tdesc" workaround
> > until the merge of his patch with other changes has occurred and we can apply
> > something which reflects the upstream changes. Comments?

I'm not a GDB expert but it is likely that I'll have to implement the target
part of support for VFP registers. I'll have a lot of questions then, but for
the time being is this: would it be possible to also provide similar workaround
(xml file) for VFP?

> 
> There's still a bit of discussion (due to uncertainty on my part in fact), but
> you can be pretty confident something similar to the following (post-merge)
> patch will be applied:
> http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html
> 
> Or you can leave it out if you don't intend these tools to be the final tools.

My answer is I don't know, but it is very likely that we'll have another
iteration(s) with GDB, at least in order to adopt VFP registers.

> But IMO we shouldn't ship a GDB without something akin to this fix being
> included.
> 

To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
for the time being to go with GDB as-is (or with work-around) and gain some
time for Jifl's patch + VFP support.

If we agree, I hope John can produce test release before his trip to USA.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #34 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-15 21:42:45 GMT ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > 
> > > I am quite busy this week but might find some time to build a new test release
> > > based on GCC 4.6.3. I'm not sure if we should apply Jifl's GDB patch for the
> > > 'g' packet reply issue or continue with the current "set tdesc" workaround
> > > until the merge of his patch with other changes has occurred and we can apply
> > > something which reflects the upstream changes. Comments?
> 
> I'm not a GDB expert but it is likely that I'll have to implement the target
> part of support for VFP registers. I'll have a lot of questions then, but for
> the time being is this: would it be possible to also provide similar workaround
> (xml file) for VFP?

You won't need it. You shouldn't need a target description file when using VFP.
You just have to make sure you have made the necessary changes in the stub so
that when VFP is used, it sends the registers in the format GDB expects. i.e.:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/features/arm-with-vfpv3.c?rev=1&content-type=text/x-cvsweb-markup&cvsroot=src

Bear in mind, the purpose of various changes (including the most recent) I've
made to GDB and Cortex-M was trying to give GDB the smarts to identify what to
do based on the executable you are debugging. Indeed, if you are using VFP,
then GDB should infer that from the executable automatically. The user should
have to do nothing special.

> > There's still a bit of discussion (due to uncertainty on my part in fact), but
> > you can be pretty confident something similar to the following (post-merge)
> > patch will be applied:
> > http://sourceware.org/ml/gdb-patches/2012-03/msg00377.html
> > 
> > Or you can leave it out if you don't intend these tools to be the final tools.
> 
> My answer is I don't know, but it is very likely that we'll have another
> iteration(s) with GDB, at least in order to adopt VFP registers.

I wouldn't have thought there would be a problem with GDB after my patch,
unless there is a problem with GDB's support for VFP on Cortex-M4 more
generally - not specific to eCos.

> > But IMO we shouldn't ship a GDB without something akin to this fix being
> > included.
> > 
> 
> To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> for the time being to go with GDB as-is (or with work-around) and gain some
> time for Jifl's patch + VFP support.

The version of the patch referenced from comment 32 is what I have now
committed to GDB. So that is now official.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-16 08:35:55 GMT ---
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> > > (In reply to comment #31)
> > > > 

[snip]

> You just have to make sure you have made the necessary changes in the stub so
> that when VFP is used, it sends the registers in the format GDB expects. i.e.:
> 

I am going to open a bug on Cortex-M FPU architecture and put my questions
there.

[snip]

> > To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> > for the time being to go with GDB as-is (or with work-around) and gain some
> > time for Jifl's patch + VFP support.
> 
> The version of the patch referenced from comment 32 is what I have now
> committed to GDB. So that is now official.

This gives us a new prospective. I would try immediately. Two questions that
will save me some time:

     - Which GDB: version/backport, snapshot or take it from CVS?
     - Is it still necessary have to apply the eCos back-trace patch
(attachment 1540)?

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-16 16:08:58 GMT ---
(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #33)
> > > (In reply to comment #32)
> > > > (In reply to comment #31)
> > > > > 
> 
> [snip]
> 
> > You just have to make sure you have made the necessary changes in the stub so
> > that when VFP is used, it sends the registers in the format GDB expects. i.e.:
> > 
> 
> I am going to open a bug on Cortex-M FPU architecture and put my questions
> there.
> 
> [snip]
> 
> > > To sum up, I would suggest to restart testing with 4.6.3 asap. That may imply
> > > for the time being to go with GDB as-is (or with work-around) and gain some
> > > time for Jifl's patch + VFP support.
> > 
> > The version of the patch referenced from comment 32 is what I have now
> > committed to GDB. So that is now official.
> 
> This gives us a new prospective. I would try immediately. Two questions that
> will save me some time:
> 
>      - Which GDB: version/backport, snapshot or take it from CVS?
>      - Is it still necessary have to apply the eCos back-trace patch
> (attachment 1540 [details])?
> 

I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

1. Building was breaking for the file /gdb/gnu-v3-abi.c with error "variable
might be used uninitialized". It builds after following workaround:

@@ -870,7 +870,7 @@
   for (i = 0; i <= max_voffset; ++i)
     {
       struct value *vfn;
-      CORE_ADDR addr;
+      CORE_ADDR addr = 0; //VAE
       volatile struct gdb_exception ex;

       printf_filtered ("[%d]: ", i);

2. Support for VFP as the one found on Cortex-M4F appears to be missing (from
what I see in gdb/features). Cortex-M4F has vfpv4-sp-d16: VFP version 4, single
precision with 16 d registers. Note: There is vfpv2 that presents 16 d
registers but it is not quite adequate as Cortex-M4F 16 d registers are at the
same time 32 s (single precision) registers.

Considering the said above, my proposal is: At present continue with GDB as-is
and define time-frame (2-4 week) for next milestone that would be either GDB
7.3 with backport of the patch or GDB 7.4 - in both cases with addition of
Cortex-M FPU profile.

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #37 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-18 00:41:10 GMT ---
(In reply to comment #36)
> 
> I tried GDB-7.4.50.20120316 that I assume contains this patch. Two issues:

I wouldn't recommend using a random day's snapshot. I'd recommend using a
stable release with the patch applied. Hence having problems like build errors.

> 2. Support for VFP as the one found on Cortex-M4F appears to be missing (from
> what I see in gdb/features). Cortex-M4F has vfpv4-sp-d16: VFP version 4, single
> precision with 16 d registers. Note: There is vfpv2 that presents 16 d
> registers but it is not quite adequate as Cortex-M4F 16 d registers are at the
> same time 32 s (single precision) registers.

The single precision registers are just virtual halves of the double registers.
Look at the use of vfp_pseudos in arm-tdep.c. From what I can see they should
spring into existence automatically as pseudo-regs if there are d registers in
the target description, and no s registers defined (specifically GDB checks
there is no "s0"). So in theory I would expect vfp2 to be a close match.

However in practice it appears that's probably not going to help much. I
thought GDB was indeed meant to be doing the right thing based on what
registers it sees, but it looks like what VFP work there has been in public GDB
has been oriented around native Linux, and so anything VFP-related will not be
available for us. Sigh. In any case, I notice even the VFP support there refers
to cpsr, not xpsr, which is not ideal (even though it's only a name).

So it looks like we need a further patch for GDB to add the Cortex-M4 register
set after all :-/. Otherwise it will make life much for confusing for our
users, and much more awkward for anyone trying to use eCos with Eclipse
(eCosCentric would be all right because we spin our own tools anyway for
eCosPro, so if we needed this support we would just go ahead and add it, but I
don't see why eCos users should be at a disadvantage).

The easiest approach is probably a further extension of the register guessing.

> Considering the said above, my proposal is: At present continue with GDB as-is
> and define time-frame (2-4 week) for next milestone that would be either GDB
> 7.3 with backport of the patch or GDB 7.4 - in both cases with addition of
> Cortex-M FPU profile.

I don't have a way to test what you're doing, but I will attach an untested
patch which I believe should work. This is on top of the earlier patch. Let me
know how you get on with it. Once we're happy the patch works, I can get it
into upstream GDB.

Jifl

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #38 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-18 00:42:44 GMT ---
Created an attachment (id=1647)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1647)
Prospective GDB patch (against GDB trunk) for Cortex-M4F registers

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-18 13:06:07 GMT ---
(In reply to comment #39)
> Created an attachment (id=1648)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1648) [details]
> Prospective GDB patch (against GDB trunk) for Cortex-M4F registers (fixed)
> 
> Revised version of the patch I just attached - I made a silly omission. Ignore
> the previous.

Thank you Jifl.

I'll try this. However, please note that despite having double registers
d0..d15 Cortex-M4F has hardware support only for single precision FP arithmetic
so single precision view of registers (s0..s31 instead of d0..d15) would be
more useful for floating point representation of register contents. Double
precision floating point is actually done in software and does not involve
d0..d15, at least not with GCC. Single precision naturally uses s0..s31 VFP
registers. Below there is a code sample.

void main(void)
{
    volatile float fla, flb, flc;
    volatile double dla, dlb, dlc;

    printf("Enter floats: ");
    scanf("%f %f", &fla, &flb);
    printf("Enter doubles: ");
    scanf ("%lf %lf", &dla, &dlb);

    flc = fla + flb;

    dlc = dla + dlb;

    printf("%f + %f = %f\n", fla, flb, flc);
    printf("%f + %f = %f\n", dla, dlb, dlc);
}

Disassembly gives:

    flc = fla + flb;
1fff0536:    ed9d 7a0b     vldr    s14, [sp, #44]    ; 0x2c
1fff053a:    eddd 7a0c     vldr    s15, [sp, #48]    ; 0x30
1fff053e:    ee77 7a27     vadd.f32    s15, s14, s15

    dlc = dla + dlb;
1fff054a:    e9dd 0104     ldrd    r0, r1, [sp, #16]
1fff054e:    e9dd 2306     ldrd    r2, r3, [sp, #24]
1fff0552:    f007 fa3b     bl    1fff79cc <__adddf3>
1fff0556:    e9cd 0108     strd    r0, r1, [sp, #32]

Ilija

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

[Bug 1001468] eCos GNU tools 4.6.2

[bugzilla-daemon]

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

--- Comment #41 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-19 01:50:00 GMT ---
(In reply to comment #40)
> 
> I'll try this. 

Thanks.

> However, please note that despite having double registers
> d0..d15 Cortex-M4F has hardware support only for single precision FP arithmetic
> so single precision view of registers (s0..s31 instead of d0..d15) would be
> more useful for floating point representation of register contents.
> Double
> precision floating point is actually done in software and does not involve
> d0..d15, at least not with GCC.
> Single precision naturally uses s0..s31 VFP
> registers. Below there is a code sample.

Yes I know, but as per comment 37, GDB provides pseudo-regs for the single
precision registers, so you can still see them (if you can't see them after my
patch then I've missed something). It will be alongside the d0..d15 view of the
registers, in line with all other ARM VFP FPUs, and it could be argued that
since http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/BEHJADED.html
shows that you can still load and store doubles, it should still be possible to
have some means of viewing them.

Anyway, GDB has no support for any other model for the single precision
registers. Doing anything else would require quite a few GDB changes for
nothing more than cosmetic gain (the removal of the d0..15 part of the view of
registers in 'info all-reg'). Simply put, the behaviour you are looking for is
not yet possible to arrange in GDB at the moment.

Jifl

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