[Cbe-oss-dev] Support for embedded SPU ELF in dynamic libs

[Maynard Johnson]

Arnd,
In one of the review comments to our OProfile-Cell SPU profiling patch 
(see below), you mentioned that we may have to handle "an embedded spu 
ELF file in a shared library object".  You state that our current 
OProfile implementation does not support such a model.  That's a true 
statement, since we were not aware of a requirement to support such a 
model.  I gave Brian Watt a call to ask what he knew about this, and 
he's not aware of anyone who's attempted to do this and wasn't sure if 
it's a supported model.  He suggested I ask Alan Modra, who I put on cc.

      Alan, can you shed any light on this topic?

Thanks.

-Maynard

Arnd Bergmann wrote:

> On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
> 
>>Arnd Bergmann wrote:
> 
> 
>>>I don't get it. What is the app_dcookie used for? If the spu binary is
>>>embedded into a library, you are still missing the dcookie to that .so file,
>>>because you return only an offset.
>>
>>For embedded SPU app, the post-processing tool opens the PPE binary app 
>>file and obtains the SPU ELF embedded thereine, and from that, we obtain 
>>the name of the SPU binary.  Also, the app name is included in the 
>>report, along with the SPU binary filename, if the report contains 
>>samples from more than one application.
> 
> 
> That's not what I meant. If you have an embedded spu ELF file in a shared
> library object, you end up recording the file of the main PPE binary, and
> the offset of the SPU ELF inside of the .so file, but not the name of the
> .so file itself.
> 
> You also say that the you record the name of the application on purpose for
> separate SPU ELF files. My assumption was that this is not necessary, but
> I don't know much about that aspect of oprofile. My feeling is that the
> samples for an external SPU ELF file should be handled the same way that
> oprofile handles events in shared libraries on the PPU (e.g. in libc.so).
> 
> 	Arnd <><