dynamic linker in RTEMS 5 ?

[Till Straumann]

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:
  1) during startup of cexp it needs to discover what run-time linked 
objects are already present
  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().

1) can probably be avoided under RTEMS if the main executable is 
statically linked.

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?

2) If you dont' automatically link dependencies then we'd only need the 
dlinfo to provide the
     load address of the object dlopen() loaded.

Instead of 'dl_iterate_phdr' a solution could also be a callback that is 
executed after an object
has been linked.
>
> The support under the dlopen family of calls may not be exactly the same as
> Linux or Unix as we do not need to followed the sharing model. We should be
> following what the standard says.
>
>>          Looking at the a github repo I see regexp, getopt, and libtecla. Do we
>>          need all
>>          of these?
>>
>>      Some of them (libtecla) can be configured away (but it's not a good idea
>>      since it affects the user experience). All of the libraries should have
>>      benign licensing.
>>
> I am fine with libtecla being in libmisc, the standard RTEMS may benefit from it.
>
> Why is there a regexp library?
For looking up symbols.
>
>> I started adding these to the RSB as add-on libraries. There is a ticket which
>> captures my progress.
> OK.
>
>> We need to be careful about the dependencies required to build RTEMS itself.
>> This may be better as an RSB kit.
> Joel, which dependences are you thinking of?
>
> Chris