[uClibc] buildroot in an uClibc env

Joakim Tjernlund Joakim.Tjernlund at lumentis.se
Sat Feb 14 10:21:57 UTC 2004


From: "Alexandre Oliva" <aoliva at redhat.com>
> On Feb 12, 2004, "Joakim Tjernlund" <joakim.tjernlund at lumentis.se> wrote:
> 
> > @@ -381,7 +385,7 @@ void *_dlsym(void *vhandle, const char *
> >  }
> >  }
>  
> > - ret = _dl_find_hash((char*)name, handle, NULL, copyrel);
> > + ret = _dl_find_hash((char*)name, handle, 0);
>  
> >  /*
> >  * Nothing found.
> 
> Hmm...  I was wondering about this bit.  I frankly don't understand
> why it is that we used copyrel in dlsym() before.  It doesn't make any
> sense to me.  Wouldn't we get the wrong address for a symbol, i.e.,
> the address where it's defined in the shared lib, instead of the
> expected address of the copy in the main executable?

I don't know either, but the find_hash function was a mess before so I am
not sure if copyrel really meant copy relocs.
The new class_type is from glibc and it seems like good way to classify
symbols. 
 
> I was actually looking into abusing the (incorrect AFAICT) use of
> copyrel here to enable _dl_find_hash to return the address of a
> function descriptor in the FR-V FDPIC port, when the symbol it finds
> happens to be a function.

Can't you use ELF32_ST_TYPE(sym->st_info) == STT_FUNC for that?

> 
> After this change, I guess I'm going to need to add a new relocation
> class to get this effect, or give _dlsym some means to figure out
> whether the symbol is a function or not.

A new class would work if not the above STT_FUNC stuff is sufficient.
> 
> Any preference, one way or another?

Use STT_FUNC if possible.

> 
> I'm beginning to think the first alternative is better, since it would
> enable me to remove __dl_find_hash with the additional argument that I
> introduced in the FDPIC patch I posted before, and instead get
> _dl_find_hash to call some macro on the return value that, for most
> machines, simply expands to the symbol address passed as an argument,
> but on FR-V FDPIC (as well as IA64 and PPC64, when we get ports for
> these machines) would check the relocation class and the symbol type
> and, if appropriate, return the descriptor address instead of the
> symbol address.
> 
> Comments?

Not really, I don't know what FDPIC is.

     Jocke



More information about the uClibc mailing list