[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