Add dladdr & Dl_info about dlfcn-win32

[TimothyGu]

Neither dladdr nor Dl_info is POSIX.

[nicowilliams]

Neither dladdr nor Dl_info is POSIX.

Eh, it's a common and very useful extension. One use is for supporting deploy-time relocation of code on the filesystem (e.g., to open asset files relative to install location that is not known at build-time).

I have written a WIN32 version in Heimdal, in lib/roken/dlfcn.hin and lib/roken/dlfcn_w32.c.

That said, there's no way in WIN32 that I can tell to get a symbol name that an address relates to, only the module's filename. If anyone knows how to get a symbol name, I'm all ears! EDIT: Ah, there is a way, look for get_symbol_name().

[pali]

there's no way in WIN32 that I can tell to get a symbol name that an address relates to

Ou, we have not known that there is no way :-) and togther with @rhabacker we have implemented it!

dladdr pull request is now ready for merge, see: #72

[pali]

@nicowilliams: You could probably switch Heimdal to this dlfcn-win32 implementation which supports more features. dladdr() with symbol name support is going to be merged ASAP.

[nicowilliams]

Ah, I see that, #72. I might just switch Heimdal to use this when you've merged #72 (ah, you just did). The license is compatible, and I do have a use for getting symbol names.

@pali @rhabacker Do you happen to know if the new dladdr() in #72 will support DATA symbols?

[pali]

Now (really now!), I'm going to extend dladdr to support reading symbols also from EXPORT table.

About DATA symbols, I'm not sure where are they stored in PE headers...

[nicowilliams]

OK, I can always test it, but I probably won't get to it soon. Thanks!

[rhabacker]

Do you happen to know if the new dladdr() in #72 will support DATA symbols?

That has not been tested, but should be possible with minor adjustments in a different pr, when the variable is decorated with __declspec(dllexport) and __declspec(dllimport).

[nicowilliams]

@rhabacker yes, dladdr() too is not guaranteed to work for non-exported symbols, and I assume the same reasons would apply to PE.

For the curious, my immediate need is that I'm modifying a "templating" ASN.1 compiler that produces something like bytecode as named arrays of entries, and I need to either enhance those with additional metadata that... happens to be in their symbolic names anyways, or use dladdr() portably 😊. (I'm inclined to make more of those symbols static so they can be stripped and extend the template data structures with the metadata I need, and hope the net effect on object size is roughly neutral or better. That certainly seems simpler in a way, but using dladdr() would do no violence to the template generator, which is a big plus.) Beyond that, having implemented a partial dladdr() for WIN32, I'm naturally curious about the rest of it, and I thank you again for this work.

[nicowilliams]

FWIW, I don't get symbol names for pointers to data symbols. I tried applying the patch from #94 and still.

Hmm, this might be user error on my part. The variable addresses in the test in question are not in a DLL.

[rhabacker]

That has not been tested, but should be possible with minor adjustments in a different pr, when the variable is decorated with __declspec(dllexport) and __declspec(dllimport).

I suggest to add a feature request for such support.

[pali]

FWIW, I don't get symbol names for pointers to data symbols.

I have put __declspec(dllexport) unsigned char big_array[100]; into the library and then in executable I called:

__declspec(dllimport) extern unsigned char big_array[100];
...
dladdr(&big_array, &info);

and it worked, I get in info infromation about library and name of symbol big_array.

[rhabacker]

and it worked, I get in info infromation about library and name of symbol big_array.

Nice to hear. Is this result with or without #94 applied ?

[pali]

I tested it only with gcc + #94.