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" <strau...@slac.stanford.edu
<mailto:strau...@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
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
