On 22/12/17 11:06 am, Till Straumann wrote: > On 12/21/2017 05:18 PM, Chris Johns wrote: >> I am missing the reason why the list is important to cexp? Are symbols not >> enough? Sorry to be asking rather basic questions. > Sure, symbols are enough - however, cexp keeps its own symbol table(s) > with additional information (mostly a symbol's size and [elf-]type) so that > a (basic) C-type can be inferred.
Interesting, how much extra data is this? The libdl symbol table does not have this but that is only because there was no need. I am happy to consider adding this and doing so would mean the base image symbols would have the data, I assume you want to know the symbol's size and type of the exported kernel symbols. How do you manage the function signature and making sure the signature and call match? A long term project for the RTEMS Tools Project is to add libdwarf support to host tools like rtems-ld and rtems-tld so accurate function signatures can be found. > If a.so depends on b.so then cexp needs to learn about a's symbols but also > b's > and it needs to know they are from different modules (because later 'a.so' > could > be unloaded with b.so remaining linked). Currently this is explicitly handled. The change I am proposing is to have libdl scan and learn the symbols of archives or object files and perform a load/link pass. Inter-dependency between object files is handled, for example a.o and b.o reference each other, a.o is loaded with unresolved externals that are resolved when b.o is loaded. Libdl handles loading from archives. > Hmm - I guess I don't know enough about RTEMS's dlopen. Do you not > use dynamic/shared objects and libraries (with a run-time linker like ld.so) ? No shared model (we are a single process OS), code is relocated so the final result and performance is just like a statically linked executable. There is no PLT or GOT support and no PIE code. You can provide your own custom allocator to manage the memory arena and control read, write and execute attributes. The default allocator uses the heap. > Is there information about the loader/linker you use? Sorry, the only detail is in the libdl code. The load call hands off processing to the format handlers which are ELF and RAP. ELF is just a normal ELF link editor, it scans the headers and section information, determines the memory needed, allocates the memory, loads the memory with the section data, reads the symbols, loading those into a global or exported table that links that table to the main symbol table, iterates over the reloc records fixing up the section data as well as linking calls to any global symbols. The libdl code also handles C++ constructors and exception handling. You can raise exceptions in loaded modules and correctly catch and handle them. Finally libdl supports GDB debugging of modules using a process NetBSD and I think some other BSD use. There is a patch for GDB about that has not been updated and merged and I suspect would need some work after GDB switch to C++. With this support you can set pending break points to code to be loaded and once loaded and executed the target will break. Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
