glibc........ memory limitations.... ideas?

glibc........ memory limitations.... ideas?

[kd]

Hi,

I have a small question...

We are developing an embedded solution as most of the people here on the
list. This means that we (or at least I) are limited be the amount of
available memory in the units.
We for example are limited by a 2 MB flash chip that might someday be 4MB.
In maybe 1.2MB of this chip I can stuff applications that need to run on
the device.
A statically linked application (with glibc) is arround 300KB (250KB
-450KB).  which means that I can stuff maybe 3-4 statically linked
applications in the flash.

The othre option is to link the applications dinamically to glibc and
stdlibc++. libc-2.1.1.so is around 4 MB and stdlibc++ is around 2.5 MB. So
using dinamically linked
applications  is not even a possibility when you look at it. BTW : Why are
thes libraries so huge!?

Compressed filesystems is one option but that means we have to increase the
size of the DRAM and that again means increased current drain. Limited
battery resources is
one of our contraints also.

How do you guys cram all the software you want into so small space? Are
there any othre c and c++ libraries that are smaller but provides access to
threads (pthreads) and
work with linux?

Thanks, for all inputs.

K.D.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc........ memory limitations.... ideas?

[Dan Malek]

kd@flaga.is wrote:


> Compressed filesystems is one option but that means we have to increase the
> size of the DRAM and that again means increased current drain. Limited
> battery resources is
> one of our contraints also.

Just because I need to learn something today, does memory really take
that much power?


> How do you guys cram all the software you want into so small space?

I am still using the old R4 libc-1.99 and associated libararies
for this reason.

One of the differences is that glibc2 just simply has more stuff
in it, which was contained in separate libraries of the past.  If
you want lots of the workstation features in your embedded system,
you will still end up with lots of library space used.

> ... Are
> there any othre c and c++ libraries that are smaller but provides access to
> threads (pthreads) and
> work with linux?


Here again, I am a minimalist.  I don't use pthreads, as the
implementation is very heavyweight.  I just use Linux threads and
some simple atomic operations for synchronization.  I certainly
don't use C++ in a resource constrained embedded environment.
All of my embedded applications have used compressed ram disks
in Flash rom....It doesn't take long before you have an application
that needs a temporary file of some kind.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc........ memory limitations.... ideas?

[Graham Stoney]

Hi K.D.,

kd@flaga.is writes:
> A statically linked application (with glibc) is arround 300KB (250KB
> -450KB).  which means that I can stuff maybe 3-4 statically linked
> applications in the flash.

I've also been looking into this. In my case, I'm developing a POSIX threaded
Embedded C++ application in a minimal environment, which makes no use of the
standard C++ library. I do need a C library though, possibly a subset of glibc.
In theory, I should be able to build the entire library, then statically link
to only drag in what I need; however, the most trivial C program ends up at
about 200Kb with glibc 2.1.2. I filed a bug report on this, which you can see
at:
    http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1399

Looking at the symbol table from the resulting executable, there's _lots_ of
unnecessary baggage. I'd say that given the widespread presence of dynamic
linking, the glibc maintainers have perhaps paid less attention to structuring
the library so that statically linked executables are minimal size. The normal
C runtime startup code to execute main() has not historically required 200kb!

I suspect we can do much, much better than this, by seeing what is causing so
much code to be pulled in unnecessarily. Glibc is not intended to be light
weight, but I think a little work to make it more pay-only-for-what-you-use
could make a big impact.

Regards,
Graham

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc........ memory limitations.... ideas?

[Epicom]

kd@flaga.is wrote:
> 
> Hi,
> 
> I have a small question...
> 
> We are developing an embedded solution as most of the people here on the
> list. This means that we (or at least I) are limited be the amount of
> available memory in the units.
> We for example are limited by a 2 MB flash chip that might someday be 4MB.
> In maybe 1.2MB of this chip I can stuff applications that need to run on
> the device.
> A statically linked application (with glibc) is arround 300KB (250KB
> -450KB).  which means that I can stuff maybe 3-4 statically linked
> applications in the flash.
> 
> The othre option is to link the applications dinamically to glibc and
> stdlibc++. libc-2.1.1.so is around 4 MB and stdlibc++ is around 2.5 MB. So

Have you stripped them?, libc is only 1 Mb if you run strip in it.
It is still too big for 2Mb, but it can fit well in 4Mb of flash.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc........ memory limitations.... ideas?

[kd]

Hi,

I am no expert but DRAM takes a lot of current when you access it. And I
suspect that if you double the memory size the refresh cycle current is
approx doubled.
So if you have the fs also in DRAM you essentially make memory accesses
more frequently and therfore you draw more current.

I made a quick measurement on the 4MB simm, no parity, 5V  I have in my
board and it looks like the DRAM is drawing something like 10mA just in
refresh cycle (no memory accesses).
When the kernel has booted it is drawing close to 110mA. And as I
understand from the HW-engeneers 100mA is alot!! 8-)

I suspect that it is possible to "strip down" glibc. But I have no Idea how
much work that is.

Has anyone any experience with NewLib? Do you think it is easy to mix
pthread or LinuxThreads and NewLib and stdlibc++?
K.D.



                                                                                                                                                    
                    Dan Malek <dan@netx4.com>                                                                                                       
                    Sent by:                                To:     kd@flaga.is                                                                     
                    owner-linuxppc-embedded@lists.li        cc:     linuxppc-embedded@lists.linuxppc.org                                            
                    nuxppc.org                              Subject:     Re: glibc........ memory limitations.... ideas?                            
                                                                                                                                                    
                                                                                                                                                    
                    10/20/99 07:18 PM                                                                                                               
                                                                                                                                                    
                                                                                                                                                    





kd@flaga.is wrote:


> Compressed filesystems is one option but that means we have to increase
the
> size of the DRAM and that again means increased current drain. Limited
> battery resources is
> one of our contraints also.

Just because I need to learn something today, does memory really take
that much power?


> How do you guys cram all the software you want into so small space?

I am still using the old R4 libc-1.99 and associated libararies
for this reason.

One of the differences is that glibc2 just simply has more stuff
in it, which was contained in separate libraries of the past.  If
you want lots of the workstation features in your embedded system,
you will still end up with lots of library space used.

> ... Are
> there any othre c and c++ libraries that are smaller but provides access
to
> threads (pthreads) and
> work with linux?


Here again, I am a minimalist.  I don't use pthreads, as the
implementation is very heavyweight.  I just use Linux threads and
some simple atomic operations for synchronization.  I certainly
don't use C++ in a resource constrained embedded environment.
All of my embedded applications have used compressed ram disks
in Flash rom....It doesn't take long before you have an application
that needs a temporary file of some kind.


     -- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/