Re: [m68k] Restore some original predefines and cleanup m68k targetflags

[Bernardo Innocenti <bernie at develer dot com>]

Hans-Peter Nilsson wrote:

> > Not even close to uClibc with some options turned off:
>
>  [92k]
>
> Heh, I certainly didn't mean to display some wonderful
> minimalistic property of glibc! :-)  Those were ballpark figures
> to help people who don't know, to see the difference.

Well, it's not a matter of taste. glibc scales well from servers
to handhelds. But real embedded systems are just too small.

I'd see no need for uClibc if glibc development had given
enough attention to small systems.

The Linux kernel is a proof that it _is_ possible to write
feature complete and standards compliant software that can
still be configured to become very tiny.

glibc just didn't do that and created a "market" for several
small competitors such as diedlibc, klibc, uClibc and newlib.

Of course developing that many new C libraries from scratch
is time consuming. If those resources had been spent on
improving glibc, by now we'd have something really great.

On the other side, competition is good. uClibc is growing to
achieve better standards compliance and is being ported to
a broad range of platforms. Perhaps handhelds developers will
soon start to see it as a valid alternative to glibc.

If glibc and uClibc fight a battle on low/middle-end platforms,
both of them will certainly improve faster :-)


> > The whole exception handling machinery is in libgcc, not glibc
> > or uClibc. To get it to work, you just need a way to do global
> > constructors and destructors for __register_frame_info() to do
> > its job.
>
> Sigh, that's "basic functionality", not "finer points".  There
> was a thread some months ago related to cancellation points for
> OS calls, for example (IIRC) when using C++ and threads.  Not a
> priority though, I'd guess.

Hmmm, would make an interesting reading. The EH stuff is quite
fascinating. Each time I read something new about exceptions,
either advanced C++ books or ABI details, I like them even less
than I did before :-)


> > Ok, but GCC is the only piece of the toolchain that needs to know
> > whether it's target is uClinux/uClibc or not. as, ld and gdb
> > don't care at all.
>
> There are other packages *outside the toolchain* too.  At
> least so I've heard. :-)

Indeed, the reason most embedded developers hate autoconf is
that it's terribly difficult to get it to work when
cross-compiling for exotic platforms.

Once *-uclinux is in config.sub, I'd certainly like to
make the autoconf tests for fork() and mmap() fail by
default, so I'd have one less post-processing fix to
perform on my config.h files ;-)


> > To avoid patching all of them, I'm still building with the
> > m68k-elf target and using symlinks to let gcc find them.
> > I'm looking for a better solution, but so far I have no choice.
>
> Avoid patching them?  Sending in patches to get support for your
> target is part of the porting effort.  Hopefully there's not
> much work besides the config.sub (and config.guess if you can
> self-host, but I guess that's not likely), and projects can
> be expected to import them on a semi-regular basis.

But both binutils and gdb really don't care about uclinux!
They already work perfectly fine when configured for the
m68k-elf target.

I have some trivial ColdFire patches for binutils, but
they are target neutral.

And no, I can't self-host, but I could if I had a board
with 512MB of SRAM to run GCC without swap ;-)


> > It does work fine on MMU systems. It's possible, but very
> > kludgy, when you don't have an MMU and you still want to
> > preserve POSIX semantics for dynamic libraries. Then you
> > need to have multiple GOTs for the program and the libraries
> > it uses.
>
> Yeah, my answer was a bit CPU-*-linux-uclibc -centric. :-)
> Sorry, I guess I upset those MMU-challenged.  Still, you can
> certainly cook up a shlib solution for a no-mmu system.
> It seems it's a been-there-done-that item.

Over 15 years ago AmigaOS already had shared libraries on 68000
(no MMU). Libraries could only be opened dynamically, similar to
dlopen(), returning a pointer to a jump table structure. There
was general compiler support to make transparent library calls
in C programs.

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