Loading...

gcc-help@gcc.gnu.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Finding the address of a symbol in a release build Peter Waller Tue Aug 28 00:06:53 2007

I'm mostly messing around here for educational value. My desire is to
take an open source computer game (OpenTTD, if you are interested) and
instrument it at runtime with python (using ctypes in a clever way).
The only vital information is the address of a given symbol (such as a
function). Using GCCXML I can find various type information, and I can
give this and the address to ctypes to say, call arbitrary functions
at runtime.

I have been moderately successful so far. If I want to be able to
access a particular symbol at runtime, I have a map that looks
something like

symbolTable["MySymbol"] = &MySymbol;

This is all well and good but very quickly I'm going to have thousands
of these, and this is by no means the most efficient way of storing
this information.

I was wondering if it was possible to get GCC to spit out information
that could be used in this way: Take a release (as opposed to debug)
build, and tell me the address of a particluar symbol. Alternatively,
can anyone think of any better ways of doing what I am trying to
achieve?

Compiling with debug information is one way, but it enlarges the build
by some significant amount. If the debug information was separate from
the binary, that would be useful. I was wondering whether addresses
could be computed from the assembly output or some such thing.

My current technique is to use the debug build and use binutils 'nm'
to output all of the symbols and their addresses. Then I write some
code in python that uses various symbols. Those symbols that get used
I can put in the symbol table in the source, and the release version
can be used with the python scripts. This is probably a reasonable
technique forpotential users, but for developers it would be nice to
have a better way that does not involve nm.

Another question: Is there an API for accessing debug information
compiled into a binary? If I have to stick with nm, it would be good
if I could extract the names myself instead of calling an external
program to do it.

Another thing: Why can't I use dlsym on these symbols? Is there any
way to expose arbitrary symbols to the dynamic library interfaces?

Regards,

- Peter