dynamic linker in RTEMS 5 ?

Till Straumann strauman at slac.stanford.edu
Fri Dec 22 00:06:21 UTC 2017


On 12/21/2017 05:18 PM, Chris Johns wrote:
> On 22/12/2017 09:47, Till Straumann wrote:
>> On 12/21/2017 04:36 PM, Chris Johns wrote:
>>> On 22/12/2017 08:34, Joel Sherrill wrote:
>>>> On Dec 21, 2017 3:04 PM, "Till Straumann" <strauman at slac.stanford.edu
>>>> <mailto:strauman at slac.stanford.edu>> wrote:
>>>>       On 12/20/2017 02:46 PM, Chris Johns wrote:
>>>>           On 21/12/17 2:22 am, Till Straumann wrote:
>>>>               I think it would not be very difficult to add support for dlopen to
>>>>               cexpsh.
>>>>
>>>>           Great. Is there a public repo with the latest code?
>>>>
>>>>       https://github.com/till-s/cexpsh <https://github.com/till-s/cexpsh>
>>> Thanks.
>>>
>>>>           Can just the cexp part be brought into RTEMS under say libmisc?
>>>>
>>>>       In principle, yes, but I'd think it might be more useful if we add
>>>>       support for loading modules via dlopen (under linux this already works
>>>>       but I'd expect RTEMS' variant to differ; in particular I'm using dlinfo
>>>>       and dl_iterate_phdr, i.e., some sort of inspection is required).
>>> We do not support dl_iterate_phdr and I am not sure what is present in dlinfo.
>> dl_iterate_phdr is necessary to support the following:
> I see it is in Linux and FreeBSD and not the standard, this is why it was missed:
of course.
>
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/dlfcn.h.html
>
> I do not keep the ELF headers or any ELF detail about and this call is awkward
> because RTEMS supports more than ELF as a format. Further to this Linux and
> FreeBSD provide different structs so what is considered portable?
>
> If we can find a suitable struct for this call then adding it should not be
> difficult if the locking can be sorted, ie holding the RTL lock while in the
> call back. Keeping ELF data on RTEMS just in case this call is made is an
> overhead I do not like as it does not fit our embedded systems approach.
>
>>   1) during startup of cexp it needs to discover what run-time linked objects are
>> already present
> On RTEMS, if users are required to only load via cexp is this a problem?
probably not.
>
>>   2) if dlopen() automatically resolves dependencies then you need a way to
>> discover what else
>>       has been linked besides the object named by the argument to dlopen().
> It currently does not do this but I am thinking it is needed and important.
>
> 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.

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).
>
>> 1) can probably be avoided under RTEMS if the main executable is statically linked.
> I think I understand what you are saying.
>
>> BTW:
>>     how do you solve the problem of missing objects? E.g., if you link libc
>> statically then only
>>     the objects required by the 'main' program are linked. If you later dlopen an
>> something that
>>     uses a symbol from libc that wasn't referenced from the main program -- how
>> do you deal with that?
> It can be handled on the host and with target help but it is awkward and why I
> feel a dlopen call should be made to search archives and directories for .o files.
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) ?

Is there information about the loader/linker you use?
>
>> 2) If you dont' automatically link dependencies then we'd only need the dlinfo
>> to provide the
>>      load address of the object dlopen() loaded.
> OK.
>
>> Instead of 'dl_iterate_phdr' a solution could also be a callback that is
>> executed after an object has been linked.
> I am OK with the 'dl_iterate_phdr' call if we can define a suitable struct that
> works.
>
> Chris




More information about the users mailing list