public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* GCC 4.6 resourcing.
@ 2012-01-24 18:03 Ilija Kocho
  2012-01-24 21:45 ` John Dallaway
  0 siblings, 1 reply; 5+ messages in thread
From: Ilija Kocho @ 2012-01-24 18:03 UTC (permalink / raw)
  To: ecos-maintainers

Hello fellows mainainers

I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC 4.6.2, 
Binutils 22.2, GDB 7.3.1) that I would put available for display/review. 
This is my first such project so I have some questions:

1. Where shall I put:
     - Sources
     - Binaries

1.1. Regarding sources:
I am expecting (hope for) some collaboration so some VCS (CVS would do) 
would be desirable. This may imply putting complete sources, which may 
be an overkill... or not... Suggestions?

2. Branding
IMHO we should mark our tools and the right place is --with-pkgversion 
(unless it isn't, please see my question below)..

My initial proposal is: "eCos Community [GNU]tools 4.6.2-<build>"
                                   build = 0, 1, ...
                                   [GNU] - optional: GNU | gnu | void
Feel free to comment and/or give your own proposals.

Question: A technical issue: how do I quote --with-pkgversion so it 
accepts white-space?

Looking forward to your input.

Ilija

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GCC 4.6 resourcing.
  2012-01-24 18:03 GCC 4.6 resourcing Ilija Kocho
@ 2012-01-24 21:45 ` John Dallaway
  2012-01-24 23:40   ` Ilija Kocho
  2012-01-27 14:32   ` Ilija Kocho
  0 siblings, 2 replies; 5+ messages in thread
From: John Dallaway @ 2012-01-24 21:45 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: ecos-maintainers

Hi Ilija

Ilija Kocho wrote:

> I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC 4.6.2,
> Binutils 22.2, GDB 7.3.1) that I would put available for display/review.
> This is my first such project so I have some questions:

If you are happy that your arm-eabi toolchain is functional (for targets
you have at your disposal), then I see no reason not to proceed with an
initial arm-eabi test release.

Does the backtrace for an eCos thread and for HAL startup code work
reliably with GDB 7.3.1? In the past, we have seen issues where the
backtrace code can enter an infinite loop, hence the patch for GDB 6.8.50.x.

I would definitely recommend building for both Linux x86 and Cygwin x86
hosts so we reach all potential testers and get some feedback regarding
both hosts.

> 1. Where shall I put:
>     - Sources

Since the sources are full binutils/gcc/gdb releases (not snapshots),
the only real issue is maintaining the patches.

>     - Binaries

Patches and toolchain binaries should be uploaded to the eCos ftp area.

> 1.1. Regarding sources:
> I am expecting (hope for) some collaboration so some VCS (CVS would do)
> would be desirable. This may imply putting complete sources, which may
> be an overkill... or not... Suggestions?

I don't think it should be necessary to place the toolchain sources
under revision control. In the past, we have simply generated tarballs
containing the various patches and placed them on the ftp site along
with the generated toolchains. Of course, there should be a separate
tarball of patches for each version of the toolchain.

> 2. Branding
> IMHO we should mark our tools and the right place is --with-pkgversion
> (unless it isn't, please see my question below)..
> 
> My initial proposal is: "eCos Community [GNU]tools 4.6.2-<build>"
>                                   build = 0, 1, ...
>                                   [GNU] - optional: GNU | gnu | void
> Feel free to comment and/or give your own proposals.

I would suggest something like:

  --with-pkgversion='eCos GNU tools 4.6.2-20120124'

I would avoid mention of "test release", so that one of the test
releases could become a final release in due course.

I have suitably old Linux and Cygwin installations here and can generate
releases based on your patches if you prefer.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GCC 4.6 resourcing.
  2012-01-24 21:45 ` John Dallaway
@ 2012-01-24 23:40   ` Ilija Kocho
  2012-01-25  6:42     ` Sergei Gavrikov
  2012-01-27 14:32   ` Ilija Kocho
  1 sibling, 1 reply; 5+ messages in thread
From: Ilija Kocho @ 2012-01-24 23:40 UTC (permalink / raw)
  To: John Dallaway; +Cc: ecos-maintainers

On 24.01.2012 22:44, John Dallaway wrote:
> Hi Ilija
>
> Ilija Kocho wrote:
>
>> I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC 4.6.2,
>> Binutils 22.2, GDB 7.3.1) that I would put available for display/review.
>> This is my first such project so I have some questions:
> If you are happy that your arm-eabi toolchain is functional (for targets
> you have at your disposal), then I see no reason not to proceed with an
> initial arm-eabi test release.

I have tested with Cortex-M targets so far, but the multi-libs seem to 
build for same targets as 4.2.3 + additional FPU library for Cortex-M4.
Here's -print-multi-lib diff.

--- /tmp/multilib_4.3.2.out    2012-01-24 23:25:48.766547367 +0100
+++ /tmp/multilib_4.6.2.out    2012-01-24 23:25:48.770547367 +0100
@@ -23,3 +23,4 @@
  thumb/be/nointerwork;@mthumb@mbig-endian@mno-thumb-interwork
  thumb/be/xscale;@mthumb@mbig-endian@mcpu=xscale
  thumb/be/nointerwork/xscale;@mthumb@mbig-endian@mno-thumb-interwork@mcpu=xscale
+thumb/thumb2/fpu/fpv4spd16;@mthumb@march=armv7@mfloat-abi=hard@mfpu=fpv4-sp-d16

It would be wise to try at least ARM7TDMI and ARM9 before we publish, 
but I haven't such targets handy.

>
> Does the backtrace for an eCos thread and for HAL startup code work
> reliably with GDB 7.3.1? In the past, we have seen issues where the
> backtrace code can enter an infinite loop, hence the patch for GDB 6.8.50.x.

I haven't patched GDB and I haven't tested GDB much, merely used it. The 
7.3.1 rel. notes (and some former releases) mention some fixes regarding 
threads...

How can one produce the case?

Note: GDB 7.4 has just been released. Should we aim for it or be 
little-bit conservative?

>
> I would definitely recommend building for both Linux x86 and Cygwin x86
> hosts so we reach all potential testers and get some feedback regarding
> both hosts.

It would be good to have in mind several Linux distributions: My current 
is Ubuntu 10.04 LTS but forthcoming 12.04 is LTS so we should consider 
it too. Then Red Hat / Fedora ...

>> 1. Where shall I put:
>>      - Sources
> Since the sources are full binutils/gcc/gdb releases (not snapshots),
> the only real issue is maintaining the patches.
>
>>      - Binaries
> Patches and toolchain binaries should be uploaded to the eCos ftp area.

Also http://ecos.sourceware.org/build-toolchain.html shall need refresh.

>> 1.1. Regarding sources:
>> I am expecting (hope for) some collaboration so some VCS (CVS would do)
>> would be desirable. This may imply putting complete sources, which may
>> be an overkill... or not... Suggestions?
> I don't think it should be necessary to place the toolchain sources
> under revision control. In the past, we have simply generated tarballs
> containing the various patches and placed them on the ftp site along
> with the generated toolchains. Of course, there should be a separate
> tarball of patches for each version of the toolchain.

I ask this question in order to define a way of sharing information 
during development process. If tarballs do the job then it's OK.

>> 2. Branding
>> IMHO we should mark our tools and the right place is --with-pkgversion
>> (unless it isn't, please see my question below)..
>>
>> My initial proposal is: "eCos Community [GNU]tools 4.6.2-<build>"
>>                                    build = 0, 1, ...
>>                                    [GNU] - optional: GNU | gnu | void
>> Feel free to comment and/or give your own proposals.
> I would suggest something like:
>
>    --with-pkgversion='eCos GNU tools 4.6.2-20120124'

Technical question: How do I get the complete (white-space) quote? I 
have tried single', double" and backslash/ quoting and it only shows the 
first word (eCos) such as:

23:55:11> arm-eabi-gcc --version
arm-eabi-gcc (eCos) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


> I have suitably old Linux and Cygwin installations here and can generate
> releases based on your patches if you prefer.

Nice. Your production facilities would be a great help and some 
assurance for stable builds.


Ilija

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GCC 4.6 resourcing.
  2012-01-24 23:40   ` Ilija Kocho
@ 2012-01-25  6:42     ` Sergei Gavrikov
  0 siblings, 0 replies; 5+ messages in thread
From: Sergei Gavrikov @ 2012-01-25  6:42 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: John Dallaway, ecos-maintainers

Hi all

On Wed, 25 Jan 2012, Ilija Kocho wrote:

> On 24.01.2012 22:44, John Dallaway wrote:
> > Hi Ilija
> > 
> > Ilija Kocho wrote:
> > 
> > > I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC
> > > 4.6.2, Binutils 22.2, GDB 7.3.1) that I would put available for
> > > display/review.  This is my first such project so I have some
> > > questions:
> > If you are happy that your arm-eabi toolchain is functional (for
> > targets you have at your disposal), then I see no reason not to
> > proceed with an initial arm-eabi test release.
> 
> I have tested with Cortex-M targets so far, but the multi-libs seem to
> build for same targets as 4.2.3 + additional FPU library for
> Cortex-M4.  Here's -print-multi-lib diff.
> 
> --- /tmp/multilib_4.3.2.out    2012-01-24 23:25:48.766547367 +0100
> +++ /tmp/multilib_4.6.2.out    2012-01-24 23:25:48.770547367 +0100
> @@ -23,3 +23,4 @@
>  thumb/be/nointerwork;@mthumb@mbig-endian@mno-thumb-interwork
>  thumb/be/xscale;@mthumb@mbig-endian@mcpu=xscale
>  thumb/be/nointerwork/xscale;@mthumb@mbig-endian@mno-thumb-interwork@mcpu=xscale
> +thumb/thumb2/fpu/fpv4spd16;@mthumb@march=armv7@mfloat-abi=hard@mfpu=fpv4-sp-d16
> 
> It would be wise to try at least ARM7TDMI and ARM9 before we publish,
> but I haven't such targets handy.

I will be able to test new toolchain on ARM7TDMI (Little-Endian)
targets.

> > Does the backtrace for an eCos thread and for HAL startup code work
> > reliably with GDB 7.3.1? In the past, we have seen issues where the
> > backtrace code can enter an infinite loop, hence the patch for GDB
> > 6.8.50.x.
> 
> I haven't patched GDB and I haven't tested GDB much, merely used it.
> The 7.3.1 rel. notes (and some former releases) mention some fixes
> regarding threads...
> 
> How can one produce the case?
> 
> Note: GDB 7.4 has just been released. Should we aim for it or be
> little-bit conservative?

Also for GDB (for targets is mentioned above). IMHO we have to build and
'i386' toolchain to test GDB 7.X features on Qemu. 

> > I would definitely recommend building for both Linux x86 and Cygwin
> > x86 hosts so we reach all potential testers and get some feedback
> > regarding both hosts.
> 
> It would be good to have in mind several Linux distributions: My
> current is Ubuntu 10.04 LTS but forthcoming 12.04 is LTS so we should
> consider it too.  Then Red Hat / Fedora ...
> 
> > > 1. Where shall I put:
> > >      - Sources
> > Since the sources are full binutils/gcc/gdb releases (not
> > snapshots), the only real issue is maintaining the patches.
> > 
> > >      - Binaries
> > Patches and toolchain binaries should be uploaded to the eCos ftp
> > area.
> 
> Also http://ecos.sourceware.org/build-toolchain.html shall need
> refresh.
> 
> > > 1.1. Regarding sources:
> > > I am expecting (hope for) some collaboration so some VCS (CVS would do)
> > > would be desirable. This may imply putting complete sources, which may
> > > be an overkill... or not... Suggestions?
> > I don't think it should be necessary to place the toolchain sources
> > under revision control. In the past, we have simply generated tarballs
> > containing the various patches and placed them on the ftp site along
> > with the generated toolchains. Of course, there should be a separate
> > tarball of patches for each version of the toolchain.
> 
> I ask this question in order to define a way of sharing information
> during development process. If tarballs do the job then it's OK.
 
We would use Bugzilla report to collect an early set of the patches,
opinions, test results, etc. We would "maintain" a collection of the
patches there and upload a final tarball on FTP when "issue" will be
RESOLVED.

> > > 2. Branding
> > > IMHO we should mark our tools and the right place is
> > > --with-pkgversion (unless it isn't, please see my question
> > > below)..
> > > 
> > > My initial proposal is: "eCos Community [GNU]tools 4.6.2-<build>"
> > >                                    build = 0, 1, ...
> > >                                    [GNU] - optional: GNU | gnu | void
> > > Feel free to comment and/or give your own proposals.
> > I would suggest something like:
> > 
> >    --with-pkgversion='eCos GNU tools 4.6.2-20120124'

I like John's version.

> Technical question: How do I get the complete (white-space) quote? I
> have tried single', double" and backslash/ quoting and it only shows
> the first word (eCos) such as:
> 
> 23:55:11> arm-eabi-gcc --version
> arm-eabi-gcc (eCos) 4.6.2
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Dash issue? (Guess only). If even

  ="one\ two" or =one\\ two
  
... Will be expanded in "one" then try 'bash' as /bin/sh.

Check:

  % readlink /bin/sh.
  

Sergei

> > I have suitably old Linux and Cygwin installations here and can
> > generate releases based on your patches if you prefer.
> 
> Nice. Your production facilities would be a great help and some
> assurance for stable builds.
> 
> 
> Ilija
> 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: GCC 4.6 resourcing.
  2012-01-24 21:45 ` John Dallaway
  2012-01-24 23:40   ` Ilija Kocho
@ 2012-01-27 14:32   ` Ilija Kocho
  1 sibling, 0 replies; 5+ messages in thread
From: Ilija Kocho @ 2012-01-27 14:32 UTC (permalink / raw)
  To: John Dallaway; +Cc: ecos-maintainers

Hi John

On 24.01.2012 22:44, John Dallaway wrote:
> Hi Ilija
>
>
> Does the backtrace for an eCos thread and for HAL startup code work
> reliably with GDB 7.3.1? In the past, we have seen issues where the
> backtrace code can enter an infinite loop, hence the patch for GDB 6.8.50.x.

Now I have addressed GDB patches too. Here's the outcome:

File: gdb-6.8.50.20080706.patch

frame.c
     eCos backtrace hack.
     Wasn't applied, /bt/ didn't stop at /thread_entry/. I did apply all 
patches to frame.c and now it seems to work properly (Screen captures 
are below).

findvar.c
     The patches mention phrase "frame" so I assume they are related to 
frame.c patches.
     I did apply the patches but my assumption may be wrong. Need 
confirmation?

valops.c
     Same discussion as for findvar.c

infcall.c
     Was up to date.

symtab.c
     Was up to date.

dwarf2-frame.c
     Code has changed, patch is very likely obsolete.

File: gdb-6.8.50.20080706-arm.patch

The subject sources have been significantly reworked. I could identify 
that some patches have been applied and some parts reworked beyond 
recognition. Very likely that all patches are obsolete.

----- Screen captures [nc_test_slave] 
----------------------------------------

-- Before patch: ----
gdb> bt
#0  do_some_random_computation (p=<optimized out>) at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:684
#1  net_load (who=<optimized out>) at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:668
#2  0x000033be in Cyg_HardwareThread::thread_entry (thread=0x1fff28d8) 
at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:94
#3  0x00003b7a in Cyg_Scheduler::start_cpu () at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/sched/sched.cxx:402
#4  0x000033ac in reschedule () at 
/home/vae/Proekti/pd/sem/ecos_kinetis/lwip_test_install/include/cyg/kernel/sched.inl:114
#5  Cyg_Thread::exit () at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:771
#6  0x00000000 in ?? ()


-- After patch: ----

gdb> bt
#0  do_some_random_computation (p=<optimized out>) at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:684
#1  net_load (who=<optimized out>) at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:668
#2  0x000033be in Cyg_HardwareThread::thread_entry (thread=0x1fff28d8) 
at 
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:94

-------------------------------------------------------------------------------

> I would suggest something like:
>
>    --with-pkgversion='eCos GNU tools 4.6.2-20120124'

Accepted and incorporated.

>
> I have suitably old Linux and Cygwin installations here and can generate
> releases based on your patches if you prefer.

I also did some fixes/clean up/branding to GCC and I'm doing the final 
tests. I'll take Sergei's suggestion for using Bugzilla obsoleting 
feature as VCS, so later evening or during the weekend I am going to put 
all patches and scripts in a private maintainer bug - for review as well 
as for you to pick them up for building.

Ilija

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-01-27 14:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-24 18:03 GCC 4.6 resourcing Ilija Kocho
2012-01-24 21:45 ` John Dallaway
2012-01-24 23:40   ` Ilija Kocho
2012-01-25  6:42     ` Sergei Gavrikov
2012-01-27 14:32   ` Ilija Kocho

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).