Re: Help: Unwinding the C++ stack...throw, longjmp & threads

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.COM> writes:

    >> >> Certainly not.  This increase is completely unused in most
    >> >> cases.

    Joe> Mark Mitchell writes:

    >> Since glibc is usually dynamically linked, I don't see why
    >> 200K, on disk, is a big deal at all.

    Joe> One case where it might matter is Linux emergency recovery
    Joe> floppies.  A floppy only holds 1.4M (already the Debian folks
    Joe> make a special stripped-down glibc for this purpose, so it
    Joe> might be 100K extra).

Good point.  But, as you say, they're already building a special
glibc.  I think that only C++/Ada/Java/etc. applications that use
exception-handling would need the extra data; obviously, that's a
pretty small set or glibc would *already* be built with -fexceptions.

There may be systems on which glibc is used, but statically linked.
There, I would see more of an issue, as every binary would grow.  (For
example, this might be true if glibc were ported to a system without
shared library support in binutils.)  But, I think we should cross
that bridge when we come to it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com