[Gcl-devel] Re: FW: [sr #104164] Is it possible to call Windows SDK from GCL?

[Camm Maguire]

Greetigns!

"Mike Thomas" <address@hidden> writes:

> Camm:
> 
> The relevant gcc version is 3.4.2 and insertion of a prototype for sdk_hello
> just before L1 fixes that problem.  Unfortunately the missing initialisation
> function problem remains in HEAD - perhaps I've called compiler::link
> incorrectly?.
> 
> Cheers
> 
> Mike Thomas.
> 
> -----Original Message-----
> From: Mike Thomas [mailto:address@hidden
> Sent: Wednesday, 4 May 2005 12:57 PM
> To: address@hidden; Joe Lee; Mike Thomas;
> address@hidden
> Subject: [sr #104164] Is it possible to call Windows SDK from GCL?
> 
> 
> 
> Follow-up Comment #1, sr #104164 (project gcl):
> 
> Hi Joe.
> 
> Thanks for the question, the answer to which exposes a couple of bugs in GCL
> which I hope to sort out for the upcoming new release of GCL - 2.6.7.  I'll
> need to discuss these with Camm Maguire as he is better at this stuff that
> me.
> 
> The short answer to your question is to use a function called COMPILER-LINK
> which statically links a new GCL image with the new function into a new
> executable.
> 

This is indeed the short answer -- you can link in any new symbols you
want that are not present in the original image via compiler::link.
See the documentation for this function in gcl-si.{texi,info}.  What
this essentially does is build a new gcl image using a fresh call to
the system linker ld to modify the image symbol table with whatever
new code or libraries you specify.  It has the disadvantage that the
image is 'fresh' -- i.e. any work you may have done in the running
image before compiling compiler::link is lost.  Such work can be
respecified to run by hand in the fresh new image through one of
compiler::link's arguments, but this is a bit awkward to use.

What I'd like to do in 2.7.0 is to allow the user to link in new
dynamic libraries at runtime, modify the running image's symbol table,
and allow this work to be preserved across image saves via
si::save-system.  What this essentially means is that unexec needs to
add a little section to the end of the dumped image containing
relocation records for the new symbols for use by the system's dynamic
linker (ld.so on Linux), i.e. a GOT (Global Access Table).  With the
recently completed work on alpha and mips native relocations, I know
how to do this for our bfd platforms, but not yet on Windows and
MaCOSX.  Hopefully our GCL experts in these areas might be able to
shed light on this question at some point in the medium term future. 

A kludgy way of doing this without any special executable format
knowledge might be to expand the explicit C plt table (mplt in plt.c)
with a bunch of dummy entries referring to unused symbols in external
shared libs, one of which we might provide for this purpose.  Then
when new symbols are needed, these symbols could be changed.  This
would still require us to be able to find the symbol in the image's
symbol table, but at least we would not have to add any new sections,
etc.  Of course this approach is rather awkward and limited too.


> You then run that executable and call your function.
> 
> Unfortunately on GCL 2.6.6 this leads to another undefined symbol apparently
> needed for GCL's internal administration:
> 
> ============================================================
> >(compile-file "c:/cvs/stable/gcl-2.6.7pre/sdk-hello.lsp")
> 
> Compiling c:/cvs/stable/gcl-2.6.7pre/sdk-hello.lsp.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling c:/cvs/stable/gcl-2.6.7pre/sdk-hello.lsp.
> #p"c:/cvs/stable/gcl-2.6.7pre/sdk-hello.o"
> 
> >(compiler::link (list "c:/cvs/stable/gcl-2.6.7pre/sdk-hello.o"
> "libuser32.a") "
> c:/msg.exe")
> ./user-init.o(.text+0x60):user-init.c: undefined reference to
> `init_sdk_hello'
> ./user-init.o(.data+0x0):user-init.c: undefined reference to
> `init_sdk_hello'
> 'c:/raw_msg.exe' is not recognized as an internal or external command,
> operable program or batch file.
> 

To use compiler::link, you have to set the :system-p t flag in
compiler-file, or alternately (setq compiler::*default-system-p* t).
This will ensure that the init functions for each module will be
uniquely named based on the lisp filename, as compiler::link expects.
This should be mentioned in the docs.  Otherwise your call above is
fine. 

What is the sdk btw?


> Error in LET* [or a callee]: Cannot delete the file #p"c:/raw_msg.exe".
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at DELETE-FILE.  Type :H for Help.
>  1 (Abort) Return to top level.
> dbl:>>1
> 
> Top level.
> ============================================================
> 
> I tried this with the CVS HEAD version of GCL and got a gcc type error as
> shown further below.
> 
> Camm, the relevant C code was as follows:
> 
> static void L1()
> {     object *old_base=vs_base;
>       object x;
>       x=
>       sdk_hello(
>       vs_base[0]);
>       vs_top=(vs_base=old_base)+1;
>       vs_base[0]=x;
> }
> /*    C function defined by DEFCFUN   */
> 
> static object sdk_hello( object ret )
> {
> object *vs=vs_top;
> object *old_top=vs_top+0;
> {
> MessageBox( NULL, "Hello world!", "Hello demo", MB_OK );
> return ret;
> }
> vs_top=vs;
> }
> 
> 
> We'll get back to you when we have sorted these problems out.
> 
> Cheers
> 
> Mike Thomas.
> 
> ============================================================
> 
> >(compile-file "c:/cvs/stable/gcl-2.6.7pre/sdk-hello.lsp")
> 
> Compiling c:/cvs/stable/gcl-2.6.7pre/sdk-hello.lsp.
> End of Pass 1.
> End of Pass 2.
> c:/cvs/stable/gcl-2.6.7pre/sdk-hello.c:5289: error: conflicting types for
> 'sdk_hello'
> c:/cvs/stable/gcl-2.6.7pre/sdk-hello.c:5281: error: previous implicit
> declaration of 'sdk_hello' was here
> (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> -fno-zero-initialized-i
> n-bss -mms-bitfields -march=i686 -mfpmath=387 -Ic:/cvs/head/gcl/unixport/../
> h
>  -
> O3  -c -w \"c:/cvs/stable/gcl-2.6.7pre/sdk-hello.c\" -o
> \"c:/cvs/stable/gcl-2.6.
> 7pre/sdk-hello.o\"") returned a non-zero value 1.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at UNLESS.
>  1 (Continue) Continues anyway.
>  2 Return to break level 1.
>  3 Return to top level.
> dbl:>>>

Mike, two questions here:

1) This is 2.6.7pre, not CVS head, no?

2) What are lines 5289 and 5281 (with a little context) of
   sdk-hello.c? 

> 
>     _______________________________________________________
> 
> Reply to this item at:
> 
>   <http://savannah.gnu.org/support/?func=detailitem&item_id=104164>
> 
> _______________________________________________
>   Message sent via/by Savannah
>   http://savannah.gnu.org/
> 
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah