Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Benjamin Kosnik]

>http://www.develer.com/uclinux/uclinux-elf-tools/gcc-3.3.1-libstdc++-atomicity.patch

Please try to integrate this to mainline gcc/libstdc++ when you get your
assignment.

thanks,
benjamin

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

On Friday 25 July 2003 17:17, Benjamin Kosnik wrote:

> >http://www.develer.com/uclinux/uclinux-elf-tools/gcc-3.3.1-libstdc++-atomicity.patch
>
> Please try to integrate this to mainline gcc/libstdc++ when you get your
> assignment.

I will. Meanwhile, I don't mind if anyone else commits it to CVS before I'm
done with this copyright assignment hassle. I believe the patch applies to
mailinine as-is. If you want to get it sooner, please feel free to do it
in place of me.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

On Tuesday 29 July 2003 05:51, Dan Kegel wrote:

> Bernardo Innocenti wrote:
> > arm-elf was an easy pick for me since there it has a simulator in gdb
> > and it's being used as the example in the combined tree tutorial ;-)
>
> Right, but -elf target names seem to be reserved for embedded systems
> without an OS.  I'm no expert, though.  Maybe you should take a poll...

I do agree. I think the uClinux people kept using m68k-elf because they
started by porting just the Linux kernel, for which a bare-metal target
was more than appropriate.

Then they decided they didn't want to have two different sets of compilers
and left things as they were when porting the userland ;-)


> > I've built on top of that mess, but before I submit any patches
> > touching the target configuration, I'll have to create the
> > m68k-uclinux-elf myself.
>
> Hmm.  The -elf in that case seems redundant.

Why? Linux supports several binary formats, and uClinux default format
for binaries is "flat", not elf. Actually, the flat format is obtained
by converting elf binaries with the elf2flt utility.

I reckon it's a big hack, but I can understand the uClinux developers:
this solution was much easier than adding support for a new binary
format all over the toolchain and in gdb.

> > I've not yet figured out how to do it all over the toolchain, but
> > looking at config.gcc it appears to be quite straightforward.
>
> One of these days I have to submit patches to allow ppc405-*-*-* and
> ppc750-*-*-*, I'm not really looking forward to it, but I guess now that
> I'm running all the test suites, at least I have a chance of writing
> a patch that doesn't break anything.

When I'll run mine, I will be terrified when opening the log file.
What do you do if you see lots of new failures? Better not knowing :-)

> > I'll start porting those to HEAD when I've shaken out the remaining
> > bugs on the stable branch.
>
> You, sir, are a gentleman and a scholar :-)

Or a coward ;-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Daniel Jacobowitz]

On Mon, Jul 28, 2003 at 08:51:55PM -0700, Dan Kegel wrote:
> One of these days I have to submit patches to allow ppc405-*-*-* and 
> ppc750-*-*-*,
> I'm not really looking forward to it, but I guess now that I'm
> running all the test suites, at least I have a chance of writing
> a patch that doesn't break anything.

Why would you want to do that?  They're compatible systems, in general. 
--with-cpu should be all you need.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Dan Kegel]

Bernardo Innocenti wrote:
> arm-elf was an easy pick for me since there it has a simulator in gdb
> and it's being used as the example in the combined tree tutorial ;-)

Right, but -elf target names seem to be reserved for embedded systems
without an OS.  I'm no expert, though.  Maybe you should take a poll...

>>It looks like the name arm-uclinux is in use, and makes more sense than
>>arm-elf, at least to me;
>>[...]
>>I'd expect m68k-uclinux to also be popular?
> 
> With the latest official uClinux toolchain (2.95.3 based), they were
> still using m68k-elf with several unclean tweaks in the header files.
> 
> I've built on top of that mess, but before I submit any patches
> touching the target configuration, I'll have to create the
> m68k-uclinux-elf myself.

Hmm.  The -elf in that case seems redundant.

> I've not yet figured out how to do it all over the toolchain, but
> looking at config.gcc it appears to be quite straightforward.

One of these days I have to submit patches to allow ppc405-*-*-* and ppc750-*-*-*,
I'm not really looking forward to it, but I guess now that I'm
running all the test suites, at least I have a chance of writing
a patch that doesn't break anything.

> I'll start porting those to HEAD when I've shaken out the remaining
> bugs on the stable branch.

You, sir, are a gentleman and a scholar :-)
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

On Monday 28 July 2003 08:09, Dan Kegel wrote:

> > I've already built a m68k-elf toolchain ...
>
> I've noticed that, when you start trying to use the testsuites, you have
> to pay closer attention to the build/host/target names you use.

arm-elf was an easy pick for me since there it has a simulator in gdb
and it's being used as the example in the combined tree tutorial ;-)

> It looks like the name arm-uclinux is in use, and makes more sense than
> arm-elf, at least to me;
> [...]
> I'd expect m68k-uclinux to also be popular?

With the latest official uClinux toolchain (2.95.3 based), they were
still using m68k-elf with several unclean tweaks in the header files.

I've built on top of that mess, but before I submit any patches
touching the target configuration, I'll have to create the
m68k-uclinux-elf myself.

I've not yet figured out how to do it all over the toolchain, but
looking at config.gcc it appears to be quite straightforward.


> I wouldn't be suprised if you had to call your target
> m68k-unknown-uclinux-gnu to make e.g. binutils' or gcc's test suite happy. 
> Dejagnu tends to get upset if you don't have several dashes in the target
> :-)

Argh, then I'll have to struggle on this too ;-)


> Be sure to use a recent version of inetutils.  Older ones
> didn't set the environment properly in rshd.  BTW you need all three,
> probably: rshd, rlogind, and rcp.

Yes, I've read it in your docs. Thank you very much for saving me
a week worth of guessing.


> Hopefully this'll shake out a few bugs in gcc-3.3.1 before release...
> or more likely, in 3.4, if you test that...

I'm testing with gcc-3.3.1 branch because my patch apply on it as-is.

I'll start porting those to HEAD when I've shaken out the remaining
bugs on the stable branch.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Dan Kegel]

Bernardo Innocenti wrote:
> On Saturday 26 July 2003 05:28, Dan Kegel wrote:
> 
>>[Have you considered running the gcc regression tests on your new cross-compiler?]
>>http://www.kegel.com/crosstool/crosstool-0.14/doc/chroot-login-howto.html
>>covers setting up rsh and rcp into a chroot jail (convenient for testing
>>new shared C libraries without upsetting the system).
>>http://www.kegel.com/crosstool/crosstool-0.14/doc/dejagnu-remote-howto.html
>>covers bringing up dejagnu for remote testing.
>>http://www.kegel.com/crosstool/crosstool-0.14/doc/crosstool-howto.html
>>covers how to bring up and test a cross toolchain based on gcc and glibc
>>(ok, not directly applicably, but I thought I'd mention it).
> 
> 
> Thank you! I've just managed to run the testsuite for arm-elf with simulator
> with the GCC 3.3.1 branch. Guessing the correct CVS tags to use for all the
> other modules was the hardest part :-/

I've found http://www.gregorpurdy.com/gregor/ltag/
helpful in guessing CVS tags.  It reduces the search space considerably.
(It might not help much when matching up different modules, though...)

> I've already built a m68k-elf toolchain ...

I've noticed that, when you start trying to use the testsuites, you have
to pay closer attention to the build/host/target names you use.

It looks like the name arm-uclinux is in use, and makes more sense than
arm-elf, at least to me; see
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00216.html
http://sources.redhat.com/ml/binutils/2001-10/msg00564.html
http://www.uclinux.org/pub/uClinux/archive/5837.html
I'd expect m68k-uclinux to also be popular?

I wouldn't be suprised if you had to call your target m68k-unknown-uclinux-gnu
to make e.g. binutils' or gcc's test suite happy.  Dejagnu tends to get
upset if you don't have several dashes in the target :-)

 > and I've read through your docs.
> Now I just need to port rlogind to uClinux...

Be sure to use a recent version of inetutils.  Older ones
didn't set the environment properly in rshd.  BTW you need all three,
probably: rshd, rlogind, and rcp.

Hopefully this'll shake out a few bugs in gcc-3.3.1 before release...
or more likely, in 3.4, if you test that...
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

On Saturday 26 July 2003 05:28, Dan Kegel wrote:

> http://www.kegel.com/crosstool/crosstool-0.14/doc/chroot-login-howto.html
> covers setting up rsh and rcp into a chroot jail (convenient for testing
> new shared C libraries without upsetting the system).
> http://www.kegel.com/crosstool/crosstool-0.14/doc/dejagnu-remote-howto.html
> covers bringing up dejagnu for remote testing.
> http://www.kegel.com/crosstool/crosstool-0.14/doc/crosstool-howto.html
> covers how to bring up and test a cross toolchain based on gcc and glibc
> (ok, not directly applicably, but I thought I'd mention it).

Thank you! I've just managed to run the testsuite for arm-elf with simulator
with the GCC 3.3.1 branch. Guessing the correct CVS tags to use for all the
other modules was the hardest part :-/

I've already built a m68k-elf toolchain and I've read through your docs.
Now I just need to port rlogind to uClinux...

Thank you for your help.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: [ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

On Friday 25 July 2003 07:15, Chris Johns wrote:
> Bernardo Innocenti wrote:
> >  - Fix atomic operations in libstdc++ for ColdFire V2 & V3 cores
> > (iostreams now work).
>
> Is this common to all Coldire users or just uCLinux users of libstdc++ ?

The old version had special ColdFire support for vxWorks and other targets
defining the __embedded__ preprocessor symbol.

This code path was using a privileged instruction (move #0,%sr) to turn
interrupts off when updating the counter. Since uClinux also defines __embedded__,
user applications linking with libstdc++ were segfaulting on the supervisor-only
opcode.

There was also generic thread-unsafe C code to be used as a last resort.

This patch replaces all of those variants with a single case using either
TAS (for 680x0, CPU32 and 5407) or BTST, which is atomic on non-SMP systems.

> If common, could I please have a copy of the patch ?

Here it is:

  http://www.develer.com/uclinux/uclinux-elf-tools/gcc-3.3.1-libstdc++-atomicity.patch

I'm still waiting for my copyright assignment papers from FSF. Please feel free to
make a patch for GCC if you like.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

[ANNOUNCE] GCC 3.3.1 uClinux/ColdFire toolchain (20030725 snapshot)

[Bernardo Innocenti]

Hello,

A new snapshot of the developement toolchain for ColdFire-based uClinux
has been released. See:
 
  http://www.develer.com/uclinux/uclinux-elf-tools.html

Sorry for making so many announces in just a few days. This time I
have big news for those who are looking for good C++ support on uClinux:

 - Large C++ apps build and run correctly;
 - -msep-data always has been working correctly - I've noticed only now;
 - Clean-up, split and document GCC patches;
 - Fix atomic operations in libstdc++ for ColdFire V2 & V3 cores (iostreams now work).


As always, please be patient with my small bandwidth. In case no serious bugs show
up during the next few days, I will soon be moving the toolchain to a faster server.

Feedback and suggestions for squashing the remaining problems would be greatly
appreciated. A big thank you to all who have helped so far.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html