On 05/14/2010 12:33 PM, Rob Landley wrote:
> On Friday 14 May 2010 02:25:42 Timo Teräs wrote:
>> While at it, we could get rid of include/applets.h too. One very nice
>> way would be to use linker section. You can use gcc __attribute__
>> section("sectionname") [1] to put the applet definitions to separate
>> memory area. It is after that possible to iterate over the structures
>> in that special section using __start_sectionname and __stop_sectionname
>> symbols which are autocreated [2]. This is also roughly how Linux kernel
>> initcalls work [3].
>
> Actually we have vague plans to generate that in a similar manner.
>
> Linker magic is a bit non-obvious for my tastes, and also won't be able to
> automatically alphebetize them and thus lend itself to a binary search,
> reducing launch latencies in scripts...
Like the immediate text says, it's possible for linker to do the
sorting, but with some limitations.
>> Now it appears that the applets need to be sorted for binary search.
>> I haven't actually tried this, but I think linker could probably do the
>> job. Normally, the section symbols get the order the object files
>> are given to ld, but it is also possible to have the linker sort the
>> filenames alphabetically [4, 5]. This of course assumes that each applet
>> is in it's own object file, and that the object file name sorting order
>> is the same as applet name sorting order.
>>
>> This obviously depends on GCC specific attribute, and GNU LD specific
>> linking. I'm not sure how well this is supported by other compilers.
>
> With pcc and llvm getting more interesting, I'd rather _not_ add anything gnu
> specific. (One of the things I like about busybox is the ability to wean a
> system off GNU insanity.)
I consider linker sections very convenient. And those are requirement
to build bootloader or kernel on most platforms. I would assume that
llvm and e.g. icc would support this, but have not double checked.
And as said, linux kernel does use this, so any viable Linux compiler
should be supporting these. Then again, it is nice to be able to
run bb on targets which is not supported by gcc.
I do also think that it's cleaner if we have less build scripts, and the
makefile dependencies are simpler. The generator script for applet.h can
be slightly complicated on that front.
Both ways do need documentation, so I'm not sure if either of them is
more easier to maintain than the other.
But this said, yes it's still trading portability with convenience. And
we probably want to stay as portable as possible, so the linker magic
would get ruled out due to that.
>> Would this be useful approach for busybox? Or do we want to be more
>> generic and possibly just create some scripts to autogenerate the
>> applet.h? Other ideas?
>
> Script to autogenerate applet.h is what I did for toybox back in 2007.
As said, I'd be equally happy with applet.h being autogenerated. :)
- Timo
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
