[gccsdk] Shared library code and modules
leenoar at sky.com
Tue Mar 8 10:33:23 PST 2016
On 08/03/16 16:41, Theo Markettos wrote:
> On Tue, Mar 08, 2016 at 03:56:39PM +0000, Lee Noar wrote:
>> The shared library system relies on each client having a few words of
>> workspace located at &8034 (after the ELF header). This means that the
>> location of the workspace is constant, but the contents can be
>> different for each client.
>> Unfortunately, this does rule out its use in modules.
> How feasible would it be to add another initialisation/entry method that made use
> of a different shared data location?
Well, it's not just that. A module would also be missing the ELF bits
that make dynamic linking possible, such as the Global Offset Table
(GOT), the Procedure Linkage Table (PLT) and the dynamic symbol table.
> The other problem is that the pre-existing SecureSockets SWI interface means
> an entry point would be in supervisor mode, so some mode switching would be
> required. What I was trying to explore was how tricky that would be,
> assuming a synchronous SWI interface is required (ie can't just schedule a
> callback and call the user mode library later). Can a SWI call out to user
> mode, do some work and return to the caller via SVC mode, without getting
> the SWI context confused? Or can a SWI call drop into user mode code and
> fix up the stack and return address so it returns direct to the caller
> without going back up to SVC mode?
If you wanted to execute the library code in USR mode after being called
in SVC mode from a SWI, then you would have to set up the C environment
first, ie, stack, sp, sl, fp, malloc, stdio, etc.
> Can you point me in the direction of the documentation of the shared library
> system? I think we probably ought to have a wiki page with at the very
> least pointers to what can be found where - I'm happy to write such a thing
> if you point in the right direction.
in the source tree.
More information about the gcc