Re: Reverse engeneering the SMU (iMac G5, newer single-pro G5)
> 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 seems that in IOI2CControllerSMU at least all vtable accesses are
done in constructors/destructors except for
IOI2CControllerSMU::start(IOService*) and IOI2CControllerSMU::free().
I have not got time to built call graphs out of this and probably won't
for the next couple of days, but I'll get back to it as soon as I can.
Cheers
Francois
On Sun, 2005-04-17 at 03:43, Benjamin Herrenschmidt wrote:
> On Fri, 2005-04-15 at 10:37 +0100, Francois wrote:
> > Hello Franck,
> >
> > thanks a lot for your help proposal. Just to give you an idea of what I
> > know and I don't: the last assembly programming I did was on a 8 bit Z80
> > years ago (I guess I could reuse this knowledge today to program
> > dishwasher and coffee machines :-). So far, I've worked my way through
> > the ppc code I've looked at using Motorola's ppc manual [1].
> >
> > [1] http://www.freescale.com/files/product/doc/MPCFPE32B.pdf
> >
> > My hope was to get an idea of the structure of Apple's code (who is
> > calling what etc). Maybe there is no real need for that, as, as you've
> > said, symbol names are often clear enough to spot basic functions. What
> > do you think?
>
> 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.
>
> 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.
>
> Ben.
IOI2CControllerSMU:
IOI2CControllerSMU::IOI2CControllerSMU[not-in-charge](OSMetaClass const*):
00000018 lis r2,ha16(vtable for IOI2CControllerSMU)
0000001c addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::IOI2CControllerSMU[in-charge](OSMetaClass const*):
00000064 lis r2,ha16(vtable for IOI2CControllerSMU)
00000068 addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::~IOI2CControllerSMU [not-in-charge]():
00000098 lis r2,ha16(vtable for IOI2CControllerSMU)
000000a0 addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::~IOI2CControllerSMU [in-charge deleting]():
000000d4 lis r2,ha16(vtable for IOI2CControllerSMU)
000000dc addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::getMetaClass() const:
IOI2CControllerSMU::MetaClass::MetaClass[not-in-charge]():
00000170 lis r2,ha16(vtable for IOI2CControllerSMU::MetaClass)
00000174 addi r2,r2,lo16(vtable for IOI2CControllerSMU::MetaClass)
IOI2CControllerSMU::MetaClass::MetaClass[in-charge]():
000001d0 lis r2,ha16(vtable for IOI2CControllerSMU::MetaClass)
000001d4 addi r2,r2,lo16(vtable for IOI2CControllerSMU::MetaClass)
IOI2CControllerSMU::MetaClass::alloc() const:
IOI2CControllerSMU::IOI2CControllerSMU[not-in-charge]():
00000280 lis r2,ha16(vtable for IOI2CControllerSMU)
00000288 addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::IOI2CControllerSMU[in-charge]():
000002ec lis r2,ha16(vtable for IOI2CControllerSMU)
000002f4 addi r2,r2,lo16(vtable for IOI2CControllerSMU)
IOI2CControllerSMU::start(IOService*):
00000344 lis r12,ha16(vtable for IOI2CController+0x348)
00000350 lwz r12,lo16(vtable for IOI2CController+0x348)(r12)
IOI2CControllerSMU::free():
00000470 lis r12,ha16(vtable for IOI2CController+0x4c)
00000478 lwz r12,lo16(vtable for IOI2CController+0x4c)(r12)
IOI2CControllerSMU::processLockI2CBus(unsigned long):
IOI2CControllerSMU::processUnlockI2CBus(unsigned long):
IOI2CControllerSMU::processReadI2CBus(IOI2CCommand*):
IOI2CControllerSMU::processWriteI2CBus(IOI2CCommand*):
IOI2CControllerSMU::AppleSMUSendI2CCommand(unsigned long, unsigned char*, unsigned long*, unsigned char*, unsigned char):
IOI2CControllerSMU::MetaClass::~MetaClass [in-charge deleting]():
00000b04 lis r2,ha16(vtable for IOI2CControllerSMU::MetaClass)
00000b0c addi r2,r2,lo16(vtable for IOI2CControllerSMU::MetaClass)
00000b94 lis r12,ha16(vtable for IOI2CControllerSMU::MetaClass+0x8)
00000b9c lwz r12,lo16(vtable for IOI2CControllerSMU::MetaClass+0x8)(r12)
__GLOBAL__I__ZN18IOI2CControllerSMU10gMetaClassE:
__GLOBAL__D__ZN18IOI2CControllerSMU10gMetaClassE:
__start:
__stop:
Reply to: