Re: 2.6.2 postponed .. (was Re: [Gcl-devel] RE ld from 2.14.90.0.8 puts no value into undefined symbols)

[Vadim V. Zhytnikov]

Camm Maguire ?????:
> [  To sum up for people unfamiliar with gcl, gcl loads compiled lisp
> objects into its .data section, relocates the code there, and makes
> the region executable.  Certain undefined symbols, like _setjmp,
> __moddi3, etc, can wind up being undefined in the compiled lisp
> object, hence the main program needs to know how to relocate them.
> This was done earlier by relocating them to the proper place in the
> .plt table, which was in turn determined by the value of the symbol in
> the symbol table of the main executable. ]
>
> Greetings, and thanks so much for this!
>
> Alas, I tested, and this is not the problem.  This define did not
> change between .7 and .8.  This however did:

And .6 too.  I even checked by rebuilding .8 with this define set
to 1 - no effect on gcl problem. I didn't check binutils cvs though.

> elf32-i386.c
>
> @@ -3005,11 +3028,16 @@
>        if ((h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) == 0)
>         {
>           /* Mark the symbol as undefined, rather than as defined in
> -            the .plt section.  Leave the value alone.  This is a clue
> +            the .plt section.  Leave the value if there were any
> +            relocations where pointer equality matters (this is a clue
>              for the dynamic linker, to make function pointer
>              comparisons work between an application and shared
> -            library.  */
> +            library), otherwise set it to zero.  If a function is only
> +            called from a binary, there is no need to slow down
> +            shared libraries because of that.  */
>           sym->st_shndx = SHN_UNDEF;
> +         if ((h->elf_link_hash_flags & ELF_LINK_POINTER_EQUALITY_NEEDED) == 0)
> +           sym->st_value = 0;
>         }
>      }
>  
> Oh the pain the pain....
>
> Even if this is changed later, .8 is out and will cause problems for
> gcl and friends wherever it is found.

In any case it is very good that we steped on this
mine so early.


> I have a workaround, but its quite ugly.  It has to go into stable,
> and it needs further testing, so I'm going to postpone the 2.6.2
> release for another week.
>
> The workaround idea is this -- make a little list of undefined symbols
> with nm from the .o files in o/, remove those defined elsewhere by
> gcl, make a little homebrew plt substitute like
>
> typedef struct {
>   const char *n;
>   const void *f;
> } Plt;
>
> #define join(a_,b_) a_ ## b_
> #define Join(a_,b_) join(a_,b_)
> #define MY_PLT(a_) {#a_,a_}
>
> #include "undef1.h" /* headers containing undefined symbol definitions*/
> /* Replace this with gcl's own hash structure at some point */
> static int
> build_symbol_table_bfd(void) {
>
>   int u,v;
>   asymbol **q;
>   Plt mplt[]={
>     #include "undef.h" /*the set of undefined symbols*/
>   };
>
> ....
>       if (q[u]->value || q[u]->flags != BSF_FUNCTION)
>         h->u.def.value=q[u]->value+q[u]->section->vma;
>       else {
>         Plt *p=mplt,*pe=p+sizeof(mplt)/sizeof(*mplt);
>         for (;p<pe && strcmp(p->n,q[u]->name);p++);
>         if (p<pe) {
>           printf("foo %s\n",q[u]->name);
>           h->u.def.value=(unsigned long)p->f+q[u]->section->vma;
>         } else
>           printf("missing %s\n",q[u]->name);
>       }
>
> I've tested that this fixes things, the hard part is going to be the
> generation of undef.h and undef1.h in a platform independent way,
> esp. as some hidden symbols need inclusion, like __moddi3 on i386.  In
> fact, the plt search is never triggered, as the mere presence of the
> table puts in a R_386_32 reloc for the symbol as opposed to/in
> addition to a R_386_PC32, in which case the value for the symbol is
> restored in the executable.  Not a bad idea to leave this search there
> for future changes I suppose.  
>
> It would be wonderful if this could be done in a robust fashion immune
> to further binutils development. Advice appreciated.
>
> Take care,

Your fix works to me!  I was able to rebuld ANSI GCL and
Maxima CVS using this GCL without any trouble.
I'll try Axiom later today.

--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>