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

[Gabriel Paubert <paubert@iram.es>]

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