Re: [MiNT] large binaries with MiNTLib 0.55.2

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi Tomas,

On Mon, Apr 17, 2000 at 04:05:13PM +0200, Tomas Berndtsson wrote:
> "Guido Flohr" <gufl0000@stud.uni-sb.de> writes:
> 
> > The main reason for the increase in size are the new printf 
> > functions.  They offer a lot more features, less bugs and that
> > has its price.  Apart from that the entire stdio model has a
> > very high abstraction level with the same consequences.
> > 
> > BTW, how was your simple hello world program? Was it with
> > puts or with printf?
> 
> It was with printf, so I guess that made a large difference in this
> case. I haven't really compared "real" programs very well yet.

Real programs also become significantly bigger.

> The question came up when Christer Gustavsson compiled oAESis using
> the new MiNTLib, and found it to be about 50% larger, 200K vs 300K, I
> think. I don't know if he stripped the binary, though.
> 
> About stripping (programs :), do I lose anything when stripping a
> program which doesn't have debug info anyway? I know the symbol table
> shrinks, but is that used for anything when not debugging?

There are two "degrees" of symbol tables:  If you link without the
option -s the executable simply has the symbol table still included.
The symbol table can be used by disassemblers to render the
disassembly a little more readable.  If you compile with -g gcc
embeds additional debugging information for source level debugging.
These symbols mainly contain line number information, i. e. it 
makes it possible to say to which line in which file a certain
assembler instruction corresponds.  This debugging information 
is usually very large.  For example /usr/bin/rpm shrinks from more
than 1 MB to about 250 k after stripping both the debugging information
and the normal symbol table.

Currently the only use for debugging information is that you can
use the program addr2line to calculate a source line number from
a crash dump as given by the MiNT kernel.  Andreas Baer is working
on Paral to make it evaluate the debugging information too, so that
you can do source level debugging with Paral.

OK, but even the symbol table left apart, new binaries have grown. 
That's true.   Why? Try to run the test suite of the MiNTLib 0.55.2
with older MiNTLib versions.  You will see that more than 50 %
(if not most of them) will fail with older versions.  The string 
functions weren't 8 bit clean, printf and friends were hopelessly 
buggy resp. outdated, floating point support was buggy and only
partially integrated.  When you debugged software you often ended
up with a MiNTLib bug, too often.  A lot of complex functions had
been illegally simplified in old MiNTLib versions, and of course
this saved space but I suspect that these simplifications and bugs
were the reason for a lot of instabilities and these arbitrary
crashes that we all know.

But the actual problem is not that the MiNTLib has increased in
size.  The problem is the absence of shared libraries under MiNT.
However, to implement the tools necessary for shared lib support
you need a stable libc.

Ciao

Guido
-- 
http://stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de