Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)

[Francois <f.taiani@computer.org>]

Gabriel,

thanks for your explanation. Would you by chance know how to convert a
vtable entry ("vtable for IOI2CController+0x348") into some
method/attribute name?

Francois

On Mon, 2005-04-18 at 18:30, Gabriel Paubert wrote:
> On Mon, Apr 18, 2005 at 04:49:19PM +0100, Francois wrote:
> > > Note that i've started doing work on the SMU driver yesterday as the
> > > iMac G5 finally came back from Apple. I have the fan control pretty much
> > > figured out, and I'm still working on figuring out the access to the
> > > various sensors and i2c busses.
> > 
> > Great!
> > 
> > On my side I've now found how to demangle symbols in the libraries:
> > 'c++filt3' (under Darwin) does it (notice the '3' at the end, c++filt
> > does not work for some reason).
> > 
> > For instance: 
> >   otool -Vt IOI2CControllerSMU | c++filt3 | less
> > 
> > gives a nicely demangled assembly code with C++ symbols.
> > 
> > > A call graph of Apple kext would still be useful tho, and if somebody
> > > manage to figure out how to also get some sense into the c++ vtable
> > > method calls (map them to method names), that would be awesome.
> > 
> > c++filt3 is able to spot vtable access:
> >   otool -Vt IOI2CControllerSMU | c++filt3 | \
> >         grep "vtable\|^[^[:space:]]*:" > vtable-use.txt
> > 
> > I've attached vtable-use.txt to this mail. By doing 
> >   grep -B1 "vtable" vtable-use.txt | less | grep "^[^[:space:]]*:"
> > 
> > you basically get the methods is which vtables are accessed
> > inIOI2CControllerSMU :
> > 
> > IOI2CControllerSMU::IOI2CControllerSMU[not-in-charge](OSMetaClass
> > const*):
> > IOI2CControllerSMU::IOI2CControllerSMU[in-charge](OSMetaClass const*):
> > IOI2CControllerSMU::~IOI2CControllerSMU [not-in-charge]():
> > IOI2CControllerSMU::~IOI2CControllerSMU [in-charge deleting]():
> > IOI2CControllerSMU::MetaClass::MetaClass[not-in-charge]():
> > IOI2CControllerSMU::MetaClass::MetaClass[in-charge]():
> > IOI2CControllerSMU::IOI2CControllerSMU[not-in-charge]():
> > IOI2CControllerSMU::IOI2CControllerSMU[in-charge]():
> > IOI2CControllerSMU::start(IOService*):
> > IOI2CControllerSMU::free():
> > IOI2CControllerSMU::MetaClass::~MetaClass [in-charge deleting]():
> > 
> > I don't know what [in-charge] and [not-in-charge mean]. Does someone
> > know?
> 
> It's something that causes bloat in C++, as so many other «features»:
> for every constuctor and destructor, the compiler generates actually 
> two functions: one for when the constructor (resp. destructor) is called 
> from the constructor (resp. destuctor) of a derived class, one for
> when the object to construct (or destroy) is of the class the constructor
> or destructor was written for. The first case is [not-in-charge], the
> second is [in-charge]. Now I don't know the difference between
> [in-charge deleting] and other versions of [in-charge] for destructors.
> I remember something about up to 3 different destructors in some cases
> but don't quote me on that.
> 
> The worst case is when there are virtual bases and multiple inheritance: 
> the compiler generates tons of virtual tables which are only for use 
> during the contruction on the object (i.e., when the virtual functions 
> that might be called must only correspond to the already constructed 
> part of the object).
> 
> If you want to be really disgusted by the code generated by GCC in
> the case of complex inheritance, just write something using the C++
> version of gtk (gtkmm), derive a class from (for example) a Gtk::SpinButton,
> create your own constructor and look at the assembly generated
> (but you'll need some aspirin to understand it).
> 
> Anyway for gory details, there is a documentation at:
> 	http://www.codesourcery.com/cxx-abi/abi.html
> 
> 	Gabriel