Re: libbusybox is back; individual mode is introduced
On Thu, Oct 11, 2007 at 06:49:07PM +0100, Denys Vlasenko wrote:
On Thursday 11 October 2007 15:23, Bernhard Fischer wrote:
I looked into making libbusybox.so executanle itself, but
it looks like that needs a lot of linker magic for questionable
gain - I can have tiny (less than 3k) busybox executable
linked against it providing the same functionality.
Any specific reasons why do you like to have
PIE busybox-which-is-also-libbusybox?
I don't have a real use-case right now (I used to do this a while back
for XXX_main and some helpers from libbb, fwiw)
but it could be used to either
-) use XXX_main in other progs
-) use stuff from {*/,}lib*/*c in other progs
-) replace zlib, provided that a compatible interface is exported (not
yet implemented, IIRC)
As of today, *all* busybox code goes to libbusybox
if CONFIG_BUILD_LIBBUSYBOX=y, busybox binary is only
a really trivial thunk:
textdata bss dec hex filename
988 260 41252 4e4 busybox
745254 12570 12032 769856 bbf40 libbusybox.so.1.8.0.svn
Ah, i see.
This basically gives you what you want in terms
of minimizing size of the on-disk files.
PIE approach will combine these two files. Maybe it is
aesthetically nicer, but no real win in size.
PIE is nicer IMHO, yes.
The zlib case would be a very, very nice thing to have, IMO
You mean - ability to use zlip (de)compressor from busybox?
yes, exactly. think
$ ln -s busybox libz.so
and export deflate() inflate() and some other important funcs that are
exported by zlib.
(in case you
already drained your TODO list too much :)
My TODO list is
- have NOMMU test config running in qemu (need help with this)
- attack invisible sources of mem consumption,
like stack usage
- phase out lash in favor of hush
- improve hush
I hope you reverse the order of the last two points ;) But we already
talked about lash still being smaller than hush (didn't look recently
though).
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: libbusybox is back; individual mode is introduced
On Wednesday 10 October 2007 11:04, Denys Vlasenko wrote: On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote: On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote: Hi, In current svn: CONFIG_BUILD_LIBBUSYBOX works again, Very nice. Thanks for your effort. What do you think about also providing an option to use the normal busybox as a whole as .so (i.e. a PIE)? It should be easy. I only need to look how e.g. glibc makes it so that /lib/libc.so.6 is runnable by itself. Bernhard, can you elaborate? Do you want to use libbusybox as a real library ? I.e. link other programs against it beside busybox apllets? I added stuff to svn which makes libbusybox export _only_ XXX_main functions. This minimizes size, but will preclude you from calling any other function. I looked into making libbusybox.so executanle itself, but it looks like that needs a lot of linker magic for questionable gain - I can have tiny (less than 3k) busybox executable linked against it providing the same functionality. Any specific reasons why do you like to have PIE busybox-which-is-also-libbusybox? -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: libbusybox is back; individual mode is introduced
On Thursday 11 October 2007 15:23, Bernhard Fischer wrote:
I looked into making libbusybox.so executanle itself, but
it looks like that needs a lot of linker magic for questionable
gain - I can have tiny (less than 3k) busybox executable
linked against it providing the same functionality.
Any specific reasons why do you like to have
PIE busybox-which-is-also-libbusybox?
I don't have a real use-case right now (I used to do this a while back
for XXX_main and some helpers from libbb, fwiw)
but it could be used to either
-) use XXX_main in other progs
-) use stuff from {*/,}lib*/*c in other progs
-) replace zlib, provided that a compatible interface is exported (not
yet implemented, IIRC)
As of today, *all* busybox code goes to libbusybox
if CONFIG_BUILD_LIBBUSYBOX=y, busybox binary is only
a really trivial thunk:
textdata bss dec hex filename
988 260 41252 4e4 busybox
745254 12570 12032 769856 bbf40 libbusybox.so.1.8.0.svn
This basically gives you what you want in terms
of minimizing size of the on-disk files.
PIE approach will combine these two files. Maybe it is
aesthetically nicer, but no real win in size.
The zlib case would be a very, very nice thing to have, IMO
You mean - ability to use zlip (de)compressor from busybox?
(in case you
already drained your TODO list too much :)
My TODO list is
- have NOMMU test config running in qemu (need help with this)
- attack invisible sources of mem consumption,
like stack usage
- phase out lash in favor of hush
- improve hush
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: libbusybox is back; individual mode is introduced
On Tuesday 09 October 2007 23:22, Bernhard Fischer wrote: On Tue, Oct 09, 2007 at 08:13:56PM +0100, Denys Vlasenko wrote: Hi, In current svn: CONFIG_BUILD_LIBBUSYBOX works again, Very nice. Thanks for your effort. What do you think about also providing an option to use the normal busybox as a whole as .so (i.e. a PIE)? It should be easy. I only need to look how e.g. glibc makes it so that /lib/libc.so.6 is runnable by itself. A potential use-case would be for people who currently clutter their apps with system() calls. Those could use the normal foo_main() API instead. foo_main() won't work in many cases. Many applets leak memory (exiting frees it all anyway) or outright exit without returning from main(). NOFORK applets are the only ones which are safe for such usage (modulo bugs). -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: libbusybox is back; individual mode is introduced
On Tue, Oct 09, 2007 at 11:35:09PM +0200, Yann E. MORIN wrote: Breaks when cross-compiling (at least for ARM) on a x86_64: The reason is that we should use the cross-strip, rather than the native one, in scripts/trylink. Patch attached. -strip -s --remove-section=.note --remove-section=.comment $EXE -o $sharedlib_dir/libbusybox.so.$BB_VER +$STRIP -s --remove-section=.note --remove-section=.comment $EXE -o $sharedlib_dir/libbusybox.so.$BB_VER This, too will fail unless you use a strip that accepts said arguments. Didn't we have a $(STRIPCMD) that contained $STRIP plus eventual args? ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: libbusybox is back; individual mode is introduced
On Tuesday 09 October 2007 23:41:48 Bernhard Fischer wrote: On Tue, Oct 09, 2007 at 11:35:09PM +0200, Yann E. MORIN wrote: Breaks when cross-compiling (at least for ARM) on a x86_64: The reason is that we should use the cross-strip, rather than the native one, in scripts/trylink. Patch attached. -strip -s --remove-section=.note --remove-section=.comment $EXE -o $sharedlib_dir/libbusybox.so.$BB_VER +$STRIP -s --remove-section=.note --remove-section=.comment $EXE -o $sharedlib_dir/libbusybox.so.$BB_VER This, too will fail unless you use a strip that accepts said arguments. Didn't we have a $(STRIPCMD) that contained $STRIP plus eventual args? If we ever had it, it stayed in limbo, but... I seem to recall we had such a beast as make macros that would check arguments against a command, and return the argument if supported, or an alternative (or empty)... The only two incarnations of $STRIP I could find are (spaces squeezed to fill in a single line): # grep -r \\\$\\\(STRIP . Makefile: $(Q)$(STRIP) -s --remove-section=.note --remove-section=.comment \ scripts/Makefile.IMA: -$(STRIP) -s -R .note -R .comment -R .version $@ Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^| | --== °_° ==-- °.---: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL|conspiracy. | °--°---°--°° ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
