Related articles |
---|
Run time access to symbol tables bar@advtech.uswest.com (1993-01-19) |
Re: Run time access to symbol tables bliss@sp64.csrd.uiuc.edu (1993-01-20) |
Newsgroups: | comp.compilers |
From: | bar@advtech.uswest.com (Bala Ramakrishnan) |
Organization: | U S WEST Advanced Technologies |
Date: | Tue, 19 Jan 1993 21:56:58 GMT |
Keywords: | C++, debug, question, comment |
I am developing a utility to print the contents of a C++ object based on
its datatype.
I would like to know if it is possible/easy to access the symbol tables
from the executable (a.out) for the above purpose, assuming that the
corresponding .o files have been compiled with the '-g' option. For
Example, I might have:
void Bar::DoSomething()
{
...
Foo *f;
...
f = new Foo();
...
LogTheObject("Bar::DoSomething()", "*f");
...
}
If Foo is defined as:
class Foo: public BaseFoo {
...
private:
int i;
char *ip;
SomeOther s;
};
class BaseFoo:
{
...
private:
float k;
short i;
};
The output for 'LogTheObject(...)' should be:
*f = (Foo) = {i = 20; ip = "This is a Test";
s = (Someother) = {...};
*** SuperClass (BaseFoo) ***
k = 20.74; i = 0;}
when the function 'LogTheObject' is executed, at run time, it must access
the symbol tables from the a.out file (just as the way a debugger loads up
the symbol tables on startup) and print the contents similar to the
'print' statement in 'dbx'. This function 'LogTheObject' will be in a
runtime library linked with the application.
I have developed a version in which, C++ code is generated to print the
contents based on the datatypes of the data members of the object. In this
version, a in-house C++ parser is used to scan the C++ source code.
However, if I can implement the same function at runtime, I can eliminate
the additional parsing step, and the management of the generated C++
source code.
Thank you for any suggesstions
--
Bala Ramakrishnan E-mail: bar@uswest.com Phone: 303-541-6283
USWEST Advanced Tech., 4001 Discovery Dr., Boulder, CO - 80303
[On most Unix systems, the symbol table is in the a.out file but isn't
loaded into RAM with the executable code. Some systems, notably OSF/1, do
keep the full symbol table in RAM, others such as SVR4 load a smaller
symbol table with only the symbols needed for dynamic linking. You can
always thing to do is to open the executable file and read its symbol
table. You can usually deduce the name of the executable from the 0th
argument to main(). -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.