Getting function signature

[jk]

I need to get information about a given function signature on the
fly. Parameter quantity, order and type is sufficient. I've been
searching around, but I can't come up with any info. Any ideas?
Assembly solutions are welcome. Thanks. --korney

 

[Richard Bos]

I need to get information about a given function signature on the
fly.

You mean, determine a prototype, at run time, after the program has been
through both compiler and optimiser? Not generally possible; and in some
cases (often involving that optimiser) not possible even in theory. Your
compiler probably has options available to include debugging information
and possibly even functions to consult that information at run time, but
those usually have quite a negative impact on performance and code size,
and in any case are all system-specific and off-topic in this newsgroup.

Richard

 

[Walter Roberson]

I need to get information about a given function signature on the
fly. Parameter quantity, order and type is sufficient. I've been
searching around, but I can't come up with any info. Any ideas?
Assembly solutions are welcome. Thanks. --korney

There is no C standard mechanism to do that -- C makes no requirements
that any of that information be recorded in a program-accessible
means. It is not uncommon for C linkers to throw away all that
kind of symbol table information except for public function
definitions (e.g., symbols that the developer specifically marks
as "exported" or equivilent in whatever library development toolset
is in use.)

I seem to recall that gcc provides some mechanisms along these lines.

I suggest that you ask in a newsgroup that is more specific to
your development environment.

 

[korney]

There is no C standard mechanism to do that -- C makes no requirements
that any of that information be recorded in a program-accessible
means. It is not uncommon for C linkers to throw away all that
kind of symbol table information except for public function
definitions (e.g., symbols that the developer specifically marks
as "exported" or equivilent in whatever library development toolset
is in use.)

I seem to recall that gcc provides some mechanisms along these lines.

I suggest that you ask in a newsgroup that is more specific to
your development environment.

I need something general enough to be cross-platform/cross-compiler.
If all relevant data is thrown away, how is it that statically
overridden functions are matched? Thanks.

 

[korney]

I need something general enough to be cross-platform/cross-compiler.
If all relevant data is thrown away, how is it that statically
overridden functions are matched? Thanks.

nm, I answered my own questions. Thanks.

 

[Walter Roberson]

On Mar 11, 12:48 pm, (e-mail address removed)-cnrc.gc.ca (Walter Roberson)
wrote:

nm, I answered my own questions. Thanks.

Unfortunately with what appears to be the wrong answer given your
expressed constraints.

C does not have statically overridden functions. It has
static functions, which have scope to the end of the compilation
unit. The method that the compiler uses to distinguish such functions
in a debugger symbol table from other functions with the same name
is implementation dependant (if there even -is- a debugger symbol
table.) But there is no need to keep the signature of such functions
at run time, or even at link time: static file scoped functions
are local to the file in which they appear and so a code generator
itself can fully link them without needing to record the details
for intra-object linking purposes.

You choose 'nm' as the mechanism to display local symbol information
"cross-platform/cross-compiler". Unfortunately,

http://www.opengroup.org/onlinepubs/009695399/utilities/nm.html

DESCRIPTION

This utility shall be provided on systems that support both the
User Portability Utilities option and the Software Development
Utilities option. On other systems it is optional.


In practice, it is not uncommon for a vendor's nm to only work
with the vendor's software development environment, and not to
be able to pull local symbols out of (for example) gcc's debugging tables.

[OT]
For example SGI IRIX's nm works fully with ELF files, not with DWARF.
Full DWARF symbols in IRIX requires using dwarfdump
[/OT]

I would not -expect- nm to work with Microsoft's development tools;
though as I am not a user of said tools, I could hope to be pleasantly
surprised.

 

[Richard Tobin]

I need something general enough to be cross-platform/cross-compiler.

There isn't anything.

If all relevant data is thrown away, how is it that statically
overridden functions are matched?

I'm not sure exactly what you mean here, but all function names are
resolved to addresses at compile or link time, so there's no need to
retain that information.

-- Richard

 

[Gordon Burditt]

I need to get information about a given function signature on the

fly. Parameter quantity, order and type is sufficient. I've been
searching around, but I can't come up with any info. Any ideas?
Assembly solutions are welcome. Thanks. --korney

From the source code? Have you looked at cproto? It generates
declarations of functions in a source file (and what it includes)
from the source file. You still need to parse the declarations.
That also requires understanding the typedefs that might show
up in the declarations.

From object code? *MUCH* harder if it's even possible. It is
highly likely that two functions, differing only in the first
parameter being int in the first, and long in the second, on a
platform where long and int are the same size, will generate identical
code (and if there are no debugging symbols, identical object files
entirely.

Depending on how that parameter is actually used (it might only be
passed to other functions), it may be impossible to tell the
difference between signed int and unsigned int, int and enum, long
and pointer, etc.

 

[Bartc]

I need to get information about a given function signature on the
fly. Parameter quantity, order and type is sufficient. I've been
searching around, but I can't come up with any info. Any ideas?
Assembly solutions are welcome. Thanks. --korney

What's your input, a pointer to the function? The name of the function?

Do you have access to the source code? Is it modifiable?

If it's your source code there's nothing to stop you building a database of
the functions of interest together with their names and parameters, for
access at runtime.

Although you might into a problem trying to represent type; a general
type-spec can be quite complex.

Without such a database, there might be debug information as has been
mentioned, otherwise it will be difficult to get full information.

 

[Kaz Kylheku]

I need to get information about a given function signature on the
fly.

No such information is required to exist. It may be possible to obtain
this by parsing the database of debugging information that was
collected when the program was built. This is entirely toolchain-
specific; nothing to do with the C language.

E.g. on a GNU platform, if your program was compiled by GCC with stabs
debug info, the program can find its own path, open itself, and grok
its own debug info. It's all there: types, variables, functions.

Obviously, debuggers pull this kind of information from somewhere, and
there is a reason compilers have a special mode for compiling for
debugging!

In a debugger, you can for instance view the contents of a variable.
The debugger knows how to pull it out of storage, and what that
variable's type is so it can display it. You can inspect structure
members to arbitrary levels of nesting, etc.

Brad Beveridge wrote some Lisp code which can open a Linux kernel
module, use the debug info to grok the functions and types, and
automatically generate the foreign call bindings to be able to make
calls into the code. This allowed him to use the Lisp image as a
framework for testing the JFFS (journaling flash file system) kernel
module in user space.

http://bc.tech.coop/blog/080229.html

 

[korney]

I was making the incorrect assumption that overloaded (yes, I used the
wrong term above) functions are identified at run-time. My old PL
prof would be very disappointed in me. In any case, since it's done
statically, and I don't have a symbol table to refer to, this seems
impossible. I'll have to explore alternative routs. Thanks again for
the explanations.

 

[Amandil]

I was making the incorrect assumption that overloaded (yes, I used the
wrong term above) functions are identified at run-time. My old PL
prof would be very disappointed in me. In any case, since it's done
statically, and I don't have a symbol table to refer to, this seems
impossible. I'll have to explore alternative routs. Thanks again for
the explanations.

The word overloaded is _definitely_ the wrong word to use: it implies
that you are using C++, which is not the topic of this newsgroup. See
comp.lang.c++ instead.

Be aware that all the above "no" responses were assuming C. In C,
there is no way of knowing the prototype of a function without the
source code (or at least a declaration in a header file). C++,
however, uses "name mangling", to encode the name of the function and
its prototype into a messy looking external symbol which is resolved
at link time. In this case, you may be able to use the external
symbols in the executable (or at least in the object file) to figure
out what the original declaration was. There are even some tools for
this; I don't know any by name, as I don't use C++ that much. (All
this is of course strictly off topic, although I hope you got a nudge
in the right direction.)

BTW, if the function you're looking to call was declared as "extern
C", name mangling is turned off (and you can't overload that
function), and you're back to the good ol' C responses above: No, you
can't find the signature of a function without the source code.

-- Marty Amandil (Peeking into uncharted territory...)

 

[Keith Thompson]

I need to get information about a given function signature on the
fly. Parameter quantity, order and type is sufficient. I've been
searching around, but I can't come up with any info. Any ideas?
Assembly solutions are welcome. Thanks. --korney

Please try to use a consistent name; you've posted in this thread
as both "jk" and "korney".

There is no portable solution in C for what you're trying to do.

What do you intend to do with the information once you've gotten it?
Perhaps there's a better solution to your underlying problem (which
would be nice, since there is no solution to your stated problem).