Re: lt_dlsym() Doesn't Allow for a Symbol with Address of 0.

[Ralph Corderoy]

Hi Peter,

> > I investigated a problem on the llvmdev mailing list where someone was
> > trying to find the value of a symbol that has an address of 0.
> > 
> >     $ nm /System/Library/Frameworks/Foundation.framework/Foundation |
> >     > grep .objc_class_name_NSAutoreleasePool
> >     00000000 A .objc_class_name_NSAutoreleasePool
> >     $
> 
> It is not possible to lookup this symbol on Mac OS X with dlsym()
> because it does not have an underscore prefix.

I don't know if dlsym() is being used on Mac OS X, I just went looking
there because I understand it behaviour.

> If you dlsym(handle,"foo") on Mac OS X, it will actually look for
> "_foo" (because if you have a C function or variable named foo, it
> gets an underscore prepended in the object file).

It could well be that some other find_sym is being used on a Mac OS X
build of LLVM.

> It is also not necessary to look up objective C symbols, as far as I
> am aware, objective C modules are bound fully when loaded and are
> always loaded globally (I may be wrong on this, please feel free to
> correct me).

Part of LLVM is a C compiler.  Andy Kitchen is trying to build some
Objective C with it.  Producing an executable from the LLVM bytecode
that the compiler generates works fine, and the executable runs.  But
running the LLVM bytecode interpreter fails;  one of the things the
interpreter tries to do is dynamically load the symbols required using
lt_dlsym.

    http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-July/009992.html

But my point applied to any symbol generated by a compiler that has an
address of 0.

> In the rest of your email, you suggest that NULL is a valid return and
> can indicate that a symbol was actually found. I was not previously
> aware of this, I'll look it up.

Thanks, my dlsym(3) on Ubuntu Linux warns me it can return NULL when the
found symbol has an address of 0 and to use dlerror() twice to find out
what really happened.

Cheers,


Ralph.