Re: [gccsdk] Shared library code and modules

On 07/03/16 23:13, Matthew Phillips wrote:
> There is a thread running on the ROOL forum regarding SecureSockets, a ratehr
> elderly module which provides a SWI interface for SSL/TLS communication:
> https://www.riscosopen.org/forum/forums/5/topics/3955?page=1
>
> As part of the discussion it was suggedted by Theo that the best way to
> update SecureSockets would be to write a shim module which would link to a
> shared library port of OpenSSL or similar. This would have the advantage that
> the security code in the preferred library could easily be updated without
> rebuilding the module.
>
> Is such an approach possible? I have very little understanding of how the
> shared library ELF loader works, and the thread has now got diverted onto
> whether German ISPs insist on a more recent SSL version than SecureSockets
> supports.
>
> Is there a good guide to what really happens behind the scenes when a shared
> library is loaded? I don't even know what memory space these things live in.

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.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK