dynamic linker in RTEMS 5 ?

Till Straumann strauman at slac.stanford.edu
Fri Dec 22 16:45:34 UTC 2017


On 12/22/2017 12:07 AM, Sebastian Huber wrote:
> On 22/12/17 00:18, 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:
>>
>> 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.
>>
>
> At least at the moment all RTEMS targets use ELF. I removed all 
> non-ELF support in Binutils for obsolete RTEMS targets in January 2017.
>
Good news.
> It would be nice to have the ELF headers in RTEMS (or Newlib) also for 
> simple bootloaders.
FWIW - I had (a while ago) created the pmelf library (which is 
distributed with cexpsh but can be unbundled).

The primary goals were:
  - independent licensing
  - only read pieces of a file which are actually needed. Most ELF 
libraries I know start with reading
    the full file into memory and then go to town. pmelf tries to avoid 
that.



More information about the users mailing list