Help: Unwinding the C++ stack...throw, longjmp & threads
Mark Mitchell
mark@codesourcery.com
Tue Aug 24 17:08:00 GMT 1999
>>>>> "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
More information about the Libc-alpha
mailing list