Re: gclcvs

[Thiemo Seufer <ths@networkno.de>]

Camm Maguire wrote:
> Greetings!  gcl uses a homemade address lookup table for functions it
> directly writes into C sources files to be compiled and loaded into
> the running image.  The code looks like this:
> 
> typedef struct {
>   const char *n;
>   unsigned long ad;
> } Plt;
> 
> #define MY_PLT(a_) {#a_,(unsigned long)(void *)a_}
> 
> static Plt mplt[]={
> 	/* This is an attempt to at least capture the addresses to
> 	   which the compiler directly refers in C code. (Some symbols
> 	   are not explicitly mentioned in the C source but are
> 	   generated by gcc, usually in a platform specific way). At
> 	   the time of this writing, these symbols alone are
> 	   sufficient for compiling maxima,acl2,and axiom on x86.
> 	   This table is not (currently at least) consulted in
> 	   actuality -- the mere mention of the symbols here (at
> 	   present) ensures that the symbols are assigned values by
> 	   the linker, which are used preferentially to these values
> 	   in sfasli.c.  FIXME -- this should be made synchronous with
> 	   compiler changes; sort the list automatically.  SORT THIS
> 	   LIST BY HAND FOR THE TIME BEING. */
> #ifndef _WIN32
> #  include "plt.h"
> #endif    
> };
> 
> =============================================================================
> plt.h:
> =============================================================================
> MY_PLT(_IO_getc),
> MY_PLT(_IO_putc),
> MY_PLT(_mcount),
> MY_PLT(_setjmp),
> MY_PLT(acos),
> MY_PLT(acosh),
> MY_PLT(asin),
> MY_PLT(asinh),
> MY_PLT(atan),
> MY_PLT(atanh),
> MY_PLT(bzero),
> MY_PLT(cos),
> MY_PLT(cosh),
> MY_PLT(exp),
> MY_PLT(fdopen),
> MY_PLT(feof),
> MY_PLT(log),
> MY_PLT(logl),
> MY_PLT(memset),
> MY_PLT(read),
> MY_PLT(sin),
> MY_PLT(sinh),
> MY_PLT(sqrt),
> MY_PLT(tan),
> MY_PLT(tanh),
> MY_PLT(write)
> =============================================================================
> 
> This has worked for quite a while, but with the latest gcc (4.1) on
> mips, I cannot avoid having the address of the gcc builtin picked up
> here, no matter if I use -fno-builtin or anything else, it seems.

This would be a bug in gcc then. Please check again and report it,
preferably with a small testcase.

> And
> for some other reason, relocating a loaded object address to the
> address of the builtin function does not return properly -- I'm
> guessing there are non-standard call sematics here.
> 
> Any idea of a workaround?  That is, short of putting in my own
> trampolines for each function:

This seems to be the only way.


Thiemo