dynamic linker in RTEMS 5 ?

[Chris Johns]

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