[uClibc] buildroot in an uClibc env

[Alexandre Oliva]

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 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.

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.

Any preference, one way or another?

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?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer