On 21/10/2013 10:13, Łukasz Stelmach wrote:
It was <2013-10-18 pią 20:16>, when Stéphane Desneux wrote:
Conclusion: stripping the binaries has a great impact:
- smaller image size: faster to load from storage,
AFAIK this is not true. Linker does not read(2) libraries, it mmap(2)s
them and accesses only the parts it needs. This is how shareing the code
works. This might be true if you do some kind of prefetch or something.
You're right: shared libs are mmaped by ld.so as you described. This is
also confirmed by the small gain on boot times.
faster to download from tizen.org (and more bandwidth for everyone
;-)) - faster application launch, at least for WRT
True.
The impact seems interesting for the launchpads (which preload some libs
with dlopen()).
Next week, I'll check more precisely why we gain 75% on the binary
size: perhaps a few libs are responsible for this... Or is this
globally distributed over all the binaries ?
I found the lib responsible for the extra 1.2GB on tizen/common: it's
/usr/lib64/libewebkit2.so . Other libs are not that big, stripped or
not. => some specific fitness program should be applied on this lib :-)
Please remember that we need those symbols for crash diagnostics. You
might want to refer to Fedoras ABRT[1] to see how a good crash reporting
system looks like. If I don't make things up, Fedora keeps some debuging
symbols to improve the process.
[1] https://fedoraproject.org/wiki/Features/ABRT?rd=Features/CrashCatcher
ABRT seems to be able to download the debuginfos on the fly to produce
more meaningfull dumps. But for Tizen it's probably not a good idea as
we don't want to fill the user device with debug files !
So we have to keep enough information in binaries to have good dumps.
I wonder if the crashreporter can produce correct reports with partially
stripped binaries: I mean we could strip the .debug_info section
(responsible for the extra weight) but keep the other symbols to have
meaningful backtraces. i.e running 'strip --strip-debug' instead of
'strip --strip-all'.
--
Stéphane Desneux
Intel OTC - Vannes/FR
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
