On 9/07/2015 5:38 am, Sebastian Huber wrote: > > You have to figure out how the linker set mechanism works in general. >
The following is a simplified view of the 'linker set' mechanism. The idea is similar to C++ static constructors and destructors without compiler and linker support automatically managing the process. The end result of the 'linker set' process is to create a section of the executable memory that is an array of values, usually pointers, to the data being managed. The run-time code knows how to find this section of memory and how to process the data it contains. The feature uses specially name ELF sections. The reason 'linker sets' exist and the need for the complexity can be seen by considering a simple example. Lets say you have a statically linked ELF application called 'app' that consists of a single ELF object file called 'a.o' linked to 'fb.o' (for FreeBSD). You can link this executable and have no unresolved external symbols. When you run this executable and it looks for specific resources there are none because you did not link any. You now build module 'm.o' and driver 'd.o' and add these to the linker command line. Again the executable links without error and this time when you run it you can find the resources present in 'm.o' and 'd.o'. How can an executable that originally linked without any unresolved externals make calls and see resources in the module and driver code by just linking them ? There cannot be any static calls to the module or driver code or we would have seen the unresolved externals, yet some how those object files have automatically bound themselves to the system at run-time and their resources have become available. The 'linker sets' do this. By linking the module and driver object files the specific data they have gets included in the specific linker 'set' and so the generic code in the 'fb.o' object file can see it and make the needed calls to the module and driver code so the resources contained in them become available. This architecture is really neat and has been implemented nicely in FreeBSD. It means FreeBSD can bind new sub-systems and drivers into the kernel without having to have complex and hard to maintain conditionals in the code based on magic compile time defines. All they do is compile the needed parts and link what is needed. A different hardware architecture is a different set of object files. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel