View Functions in library

Say I have a library file, such as cudart.so . How can I view what functions are inside the library, without reverting to a programming guide. I'm working on a Wine project, and I need to be able to look inside a library file, and get 2 things of information from it. I need to get the name of the function, and then the input that is expected.

For examples inside cudart.so there is a function called, cudaSetDevice

Pretend I didn't know that. Now I need a way to find either A)
cudaSetDevice( int device )

or B)
cudaSetDevice( long )

Everything is either a long or a pointer, and for wine I just need to know the name of the function and what input it wants, longs? pointers? both? what order? There has to be a way to find that.

You don't look at compiled libraries to find out what functions are held therein. You look at header files (.h). I'm sure there is some way to back that info out of a .so shared object, but no one would do that.

Since for a compiled binary an int is the same as a pointer, there is no way to find out what the declaration of the function is. Check the headers or the documentation.

What I am trying to do is automate the process of using native libraries in wine, by automatically creating a wrapper. In order to do this, I need a way to figure out what functions are in a dll and what are in a .so, so I can then redirect these functions to the native .so.

Try the following. I'm not sure if that is the exact solution you need, but it will show all the available functions in an object file (or an executable that has linked in files)

I have no idea if this works for .dll's though.

Roofles said:

Try the following.

Code:

nm -l *file*

I'm not sure if that is the exact solution you need, but it will show all the available functions in an object file (or an executable that has linked in files)

I have no idea if this works for .dll's though.

Click to expand...

I this is on the right track, but it seems not to work with cudart,


Any idea what it says no symbols?

Microsoft documents all the functions in their DLL's I believe. Not the implementation of course, but the header files are needed if programmers are to link to them. Try checking on the MS site... or maybe it's a paid MSDN thing or something of that sort. Not sure... I've never tried to program in MS-land, only Linux and Solaris (and Mac in school, if that counts).

MRD said:

Microsoft documents all the functions in their DLL's I believe. Not the implementation of course, but the header files are needed if programmers are to link to them. Try checking on the MS site... or maybe it's a paid MSDN thing or something of that sort. Not sure... I've never tried to program in MS-land, only Linux and Solaris (and Mac in school, if that counts).

Click to expand...

The main thing is though, this is for non-ms libraries. On top of that this is a way to have the process automated, and integrated into wine, so someone doesn't have to hunt around for documentation or header files.

I have no clue if what I am asking for exist, or how possible it is, but I'm just trying to figure it out. Now the nm seems to work with libraries I compile myself, but no go on distributed libraries. Is there a reason for this? Is there a gcc switch needed or something?

MS functions do not correspond exactly to GNU functions. The few that do have long since been incorporated into WINE.

MRD said:

MS functions do not correspond exactly to GNU functions. The few that do have long since been incorporated into WINE.

Click to expand...

I'm talking about things like CUDA, which is Nvidia's way to run programs on the GPU, or AMD's CAL/Stream. Libraries that are cross platform. There is a cudart.dll and a libcudart.so . The only difference between the two is cudart.dll includes 6 or 8 direct 3d functions, that libcudart.so doesn't have. Besides that they are the same. Both link to the Nvidia driver on your platform. Things such as Folding@home who have only released a windows CUDA/CAL client, by having a "wrapper" which redirects the function calls from cudart.dll to libcudart.so these programs work near flawlessly. (CAL doesn't work yet, but I'm hoping by adding in support for this type of operation we can fix the problems we are getting.).

So it is windows libraries but they are not microsoft, they are 3rd party. Wine a long time ago support native .so's as an option for dll override but it was troublesome as in not all functions were implemented cross platform and those that weren't caused problems for wine. So I'm thinking if I am able to only translate the particular functions that are cross platform, we can eliminate some of the problems, and other such as the direct 3d functions can be made to run through wine's translator into opengl functions and made to work. Cuda and Cal are just two examples that would benefit, there is much more, including punkbuster.

Symbols are debug information. Distributed shared libs are stripped of those.
use gcc -g or run strip on your own compiled binaries.

And you can't get the info you need from the libs alone: DLLs and .sos both have only relocation information in their export tables cause that's all that's needed. No info at all about parameters and how many of them. If you call them with the wrong amount of parameters your program just crashes.