Peter Waller wrote: > 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). If it's open source then why not modify the game to provide instrumentation hooks to do what you want instead of just poking directly at locations in memory and hoping they correspond to what you think? > 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. Assuming your platform is linux[1] and you're using a recent binutils, you can in fact create a separate file containing only the debug information. See the comments in the manual for the strip --only-keep-debug option for a step-by-step procedure for how to do this: <http://sourceware.org/binutils/docs-2.17/binutils/strip.html> > I was wondering whether addresses > could be computed from the assembly output or some such thing. The assembly output that gcc creates has not been linked, and thus has no addresses assigned yet. That is rather the whole point of linking. :) > 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. nm is built on libbfd, so I suppose you could use libbfd directly yourself, however this library is traditionally fairly tightly integrated with the binutils and so it might not be very easy to use in a standalone manner. There are also standalone DWARF readers[2] such as libdwarf: <http://reality.sgiweb.org/davea/dwarf.html> > Another thing: Why can't I use dlsym on these symbols? Is there any > way to expose arbitrary symbols to the dynamic library interfaces? In order for that to work you'd probably have to compile and link the binary with -fPIE, and any libraries containing symbols of interest would need to be built shared (which implies -fPIC.) That might have a performance impact however, because it means that what used to be local symbols whose addresses were at a known location are now accessed through a level of indirection with the GOT. That is however a requirement for having them available through dlsym. You can play around with symbol visibility in order to only expose those that you have an interest in, e.g. specify -fvisibility=hidden and then use __attribute__((visibility("default"))) on just those symbols that you want to make available with dlsym. Brian [1] You didn't state, and gcc targets dozens of platforms, so be specific. We have no idea what platform you're using unless you say so. [2] Again, assuming that you're using the DWARF debug format. Different platforms use different formats, and while DWARF is a safe bet if you're using linux, it's still a guess based on lack of detail.
