[gccsdk] Shared library code and modules

Theo Markettos theo at markettos.org.uk
Tue Mar 8 14:30:43 PST 2016


On Tue, Mar 08, 2016 at 06:33:23PM +0000, Lee Noar wrote:
> On 08/03/16 16:41, Theo Markettos wrote:
> >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.

I was thinking of a RunDll kind of interface, ie start, dlopen(), dlsym()
and then call the function pointer.  I imagine the tricky part is getting
the data areas initialised, particularly when you don't necessarily have
rights to assume things about the client's memory.

> 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.

Hmm, yes, it does look more complicated than I thought.  Unwinding the SVC
stack to the point of SVC entry you could do (would have to know how far
down it takes to call into your SWI handler, somewhat fragile), but sl you
couldn't necessarily infer unless you trusted the caller to provide its own
stack.  fp could be fixed up.  stdio might be tricky.  And malloc is a pain
because you can't allocate anything in the user process' memory - it would
probably need a dynamic area with its own allocator.

> >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.
> 
> gcc4/riscos/soloader/dist/!SharedLibs/docs/Technical
> 
> in the source tree.

Thanks.  I think I ought to stare at them and think about the issues in more
detail.

Theo




More information about the gcc mailing list