[gccsdk] Shared library code and modules

Lee Noar 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 mailing list