On Tuesday, February 5, 2002, at 03:28 AM, Ralf Baechle wrote: > On Tue, Feb 05, 2002 at 01:16:46AM -0500, Jay Carlson wrote: > >> Given that I tossed out the SVR4 ABI in search of code density in snow, >> I'm probably a little abnormal in these concerns. But other people on >> small platforms may care. > > SNOW certainly was a nice invention and the definition of small is > changing. Are you planning to keep up the support for SNOW? Yeah, although it's slow going. As usual, "which toolchain" plays a major part in the delay :-) (Quick background for the list: Because there's such a large code size penalty to PIC/abicalls, I resurrected the bad old Linux/SVR3 statically linked, dynamically loaded libraries, which are linked at absolute locations. Shane Nay took this from a cute demo to a working distribution for the Agenda VR3; Brian Webb helped. Typical code reduction is ~25-40%, eg 391k->272k.) I think I finally have a working jumptable implementation, which should allow (careful!) upgrades of libraries without triggering app rebuilds. The pain was not actually jumptables themselves; it was getting all exported data in a library shuffled around so it could live at fixed addresses. -fdata-sections let me do most of this with linker scripts. Unfortunately, g++ was still emitting "int foo;" in ".bss", so I had to fix it to generate the proper ".bss.foo". I created a toolchain builder based on the RH71 SRPMs. About halfway through this, I remembered why I hadn't upgraded from glibc 2.0 to 2.2 before---the library size doubled. So after getting a few huge statically linked executables tested to make sure the toolchain was sound, I backtracked to uclibc and the old Agenda glibc "2.0.7". I have plausible-looking builds of both, but I haven't actually run them on real hardware..... (Is there any hope of patching glibc 2.2.4 with the sglibc patches? If so, how?) I started writing a /lib/ld-snow.so.1 to get the library loading code out of the main body of executables. I'm hoping to have a beta of a full toolchain/library build tool shipped this weekend or next, and from there hook into the community efforts to automate rebuilding the Agenda VR3 from source. I figure X and a pile of C++ fltk apps will expose any lingering bugs in the toolchain and new bugs in the shared library mechanism. I'd like to be less Agenda-centric. I think this work would benefit the Helio as well as other small platforms. But as you say, the definition of "small" is changing; hopefully in few years, machines will be big enough to support the SVR4 ABI without second thoughts. I don't know; it's possible that the really low end machines will just get cheaper instead of bigger. Speaking of small, anybody have a Linux box with a CPU with working MIPS16 support? (Other than Vr41xx; I have plenty of those to test on.) I have a small test case I'd like someone to run. Jay
