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:
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
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
