[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    RE: [uClinux-dev] Saving space by deleting symbols
From:       "Friedrich, Lars" <lars.friedrich () wago ! com>
Date:       2005-04-29 6:34:13
Message-ID: AB4979EC12A5EB419810807434495A17283CF5 () svex01001 ! wago ! local
[Download RAW message or body]

> I am wondering whether it would be possible to force
> gcc/ld to only selectively define data and functions
> that main() depends on e.g. using the '--defsym SYMBOL=null'
> ld option for unused functions.  Has anyone ever tried this?

This doesn't make sense to me.

a) defsym just defines symbols. Assuming it is able to overwrite
existing symbols, you wouldn't win anything. MYSYMBOL=00000000
takes up as much space as MYSYMBOL=0x47823288 (granted, you save
2 byte because zlib can compress it better maybe).

b) With objcopy you can actually strip symbols from a file and
have them removed when generating a new file. But

c) If a function from a library isn't needed, it doesn't get linked
in anyway. The linker only resolves symbols and doesn't add them
(except necessary crt startup functions). The only functions you could
omit are those that never get called _and_ are within the application you
compile. With -Wunused(-function) you will get a warning about such
unused functions, so there is most likely nothing to omit if you don't
get the warning. Every function you want to omit which doesn't generate
an unused warning might cause sideeffects when removed, so you need to
check the sourcecode and if you do this anyway, you can just #if out
any code you feel is unnecessary.

> Also, I have occasionally run into problems with the length 
> of time that it takes to start up a large zflat file - e.g. 
> busybox.  Is this because the .data segment has to be 
> unzipped every time the binary is called?

I don't notice any time problem with compressed flat files
or uncompressing busybox and I seriously doubt that time
related problems come from the amount of work to uncompress
some data. If you would have such a touchy architecture,
you couldn't use the userspace at all.

> If so, would it be safe to invoke schedule() during the zlib
> calls, or is it possible to compress only the .text segment
> using flthdr?

It should be always safe to call schedule() in the kernel,
except in areas without process context like the IRQ handlers.

> Finally, I would like to know if anyone knows of a way of
> checking for stack overflows with a fixed size stack on an
> MMU-less micro.

There has been a patch floating around for timer irq based
checking of stack overflows, no idea if it was put into cvs.

Best regards,
Lars Friedrich
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org

[prev in list] [next in list] [prev in thread] [next in thread]