C programming: dladdr() not available in HP-UX; any alternatives ?

[Peter Van Nieuwenhoven]

Hi,

While porting a Linux application, I am stuck on the usage or dladdr(), whitch gives (in Linux) a struc, wherefrom the app takes the filename. The functions dlopen(), dlsym(), ... exist on HP-UX (with the correct patches), but dladdr() does not. Why ? Maybe that's not important, but I still need that functionality.
So, how can I obtain the filename of a loaded module, when I only got the address ? (In the C language off course)

Thanks

[Jeff Schussele]

Hi Peter,

I'm not a C coder, but what about

dlget

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90683/B2355-90683_top.html&con=/hpux/onlinedocs/B2355-90683/00/01/113-con.html&toc=/hpux/onlinedocs/B2355-90683/00/01/113-toc.html&searchterms=dlopen&queryid=20030220-093254

or

dlgetmodinfo

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B3921-90010/B3921-90010_top.html&con=/hpux/onlinedocs/B3921-90010/00/13/1323-con.html&toc=/hpux/onlinedocs/B3921-90010/00/13/1323-toc.html&searchterms=dlopen&queryid=20030220-093254

HTH,
Jeff

[Peter Van Nieuwenhoven]

Jeff,

I allready studied these functions, but I still don't know how to retrieve a filename from the data these functions provide.

Thanks anyway.

[A. Clay Stephenson]

I've never had a need for this routine but it appears that dlgetname() is the guy you want.

[Peter Van Nieuwenhoven]

A. ,

dlgetname() does the trick allright, but only in 64 bit mode. I have to compile and link the code in 32bit, so 64bit code is out of the question.

Does anybody know any alternatives ?

Maybe the programmer who ported dlopen, dlsym etc. can explain why the dladdr functionality was not portable...

Thank U

[Adam J Markiewicz]

Hi

I've checked man dlgetname() and didn't find anything that it's only for 64-bit...

However all pointers are declared as long long (probabilly for compatibility between 32 and 64 bit).

But mayby that can cause your problem - check carefully MSB of the pointer. If it is set, the value can be interpreted negative and casting it to long long can give you address not interpretable in 32-bit.

Hope I've helped a bit

Adam

[Peter Van Nieuwenhoven]

By the way, I'm working on an A400 machine, which is 64bit, but I need the program to run on a B132 (32bit) also.

Here's a portion of the man page:
--------------------
dlgetname(3C) dlgetname(3C)
64-Bit Applications Only

NAME
dlgetname - retrieve the name of a load module given a load module
descriptor
--------------------
It clearly states '64-Bit Applications Only'
I tried the code, but you have to link with the 64-bit library 'dl', and that gives the trouble.

Now I'm investigating the shl_xxxx routines, but It is not that easy to mimic the behaviour of the Linux code.

Let me try to explain exactly what the routine tries to do:

It uses the address of a (dummy) function inside a module, and with that address, it tries to lookup the filename of the given module. That filename is needed further in the source to create files based on that name.

Anyone familiar with the shl_xxxx routines ?

[Adam J Markiewicz · Accepted solution]

Ok, checked with another server, same results (64-bit only).
But it means that the whole interface is for 64-bit, not only this particular function. Had simmilar problem once.

My solution for you:

#include
char *findname( void *fun_addr )
{
struct shl_descriptor desc;
for(int index = 0 ; !shl_get_r( index, &desc ) ; ++index ) {
if(
(desc.tstart <= (unsigned long)fun_addr) &&
(desc.tend > (unsigned long)fun_addr)
) return desc.filename;
}
return NULL; // ???
}


Good luck

Adam

[Adam J Markiewicz]

Ooops... Not so easy...

desc.filename is an array, not a ptr(!!!!), so it MUSN'T be returned as a result from a function.

However I think you'll manage to rework this by your own.

Sorry for confusion.

Adam

[Peter Van Nieuwenhoven]

I've found approx. the same solotion myself, but I'll award the points to you anyway.

Thank you very much.

[Mike Stroyan]

Here is a dladdr that I implemented around the shl functions. One warning is that function pointers are not really the address of code but the address of a PLT record with a pointer to the code. The tester.c example shows how to use a function pointer to get a real code address to pass to dladdr.