Jay,
Excellent info! Here's some points:
MCrowe@MCrowe lib $ nios2-elf-size /tmp/lua.o
text data bss dec hex filename
111152 1261 0 112413 1b71d /tmp/lua.o
MCrowe@MCrowe lib $ nios2-elf-size --total `flib c` | tail -1
153213 3066 748 157027 26563 (TOTALS)
Therefore (I think), most of the uClibc is getting pulled in, right?
Since this is an embedded system, I was trying to determine what flash
memory size lua was going to take up.
I see what you mean about sprintf and the -nm command. I'm looking
through that now.
uClinux does not have an MMU, so I'm stuck with static, I guess.
Currently, we only offer C/C++ as languages, and I wanted to offer a
higher level language, and lua appears to be it.
I'm hoping that Lua + compiled lua-code will be better than porting a
JVM to language. Thoughts?
Thanks, Jay!
Mike
Jay Carlson wrote:
Mike Crowe writes:
MCrowe@MCrowe lua $ l lib
total 128
-rw-rw-rw- 1 MCrowe mkpasswd 130638 Oct 19 21:59 liblua.a
-rw-rw-rw- 1 MCrowe mkpasswd 92316 Oct 19 21:59 liblualib.a
MCrowe@MCrowe lua $ l bin
total 395
-rw-rw-rw- 1 MCrowe mkpasswd 403948 Oct 19 21:59 lua
MCrowe@MCrowe lua $
"I don't see the problem."
Oh, you mean that it's much bigger than you expected? My guess is that it's
pulling in substantial parts of libc and libm. That's not surprising, given
that one of Lua's informal missions is to use every part of ANSI libc and
libm.
I'm guessing your architecture doesn't have dynamic loading for shared
libraries. FWIW, it's not that hard to write a dynamic loader; I did one
for mipsel-linux for PDAs a while ago. Lemme know if you want hints.
Dynamic linking, OTOH, is No Fun.
....ohhh, you don't have an MMU. Ugh. Shared libraries are going to need
toolchain support if not source modifications. I can get paid for that
level of work since it, as well, is No Fun.
(I believe my last message to the list included criticism on the basis of
fun, so I feel like I'm allowed to spam that word some more.)
For fun, try running these commands:
# Find the absolute path of a shared library
flib () { nios2-elf-gcc -print-file-name=lib$1.a ; }
# Partially link lua and lualib, resolving all internal references
nios2-elf-ld -r --whole-archive `flib lua` `flib lualib` -o /tmp/lua.o
# Get the actual linkable size of that
nios2-elf-size /tmp/lua.o
# Compare with libc:
nios2-elf-size --total `flib c` | tail -1
# Browse through the functions Lua is calling for in libc
nios2-elf-nm /tmp/lua.o | grep ' U ' | more
After that, you'll have to start hunting through linker maps to see how Lua
calling for sprintf drags in huge chunks of other libc stuff.
In general, you get more geek points if you complain about bloat via the
size command rather than ls, which includes lots of other overhead which may
or may not affect execution size.
Did you already get rid of the libm dependencies?
Jay
--
Signature
In Him, Mike
|
