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

[Brian Watt]

All,

Just to make sure, I'm no expert in all this.

Case 1: I only stated that I know of no one who has developed an SPU 
executable that links with SPU shared object libraries (.so files) which 
are dynamically loaded either at load time or run time. All I am aware of 
is an SPU executable bound wiht SPU static libraries during link time. 
This is all I was talking about with Maynard.

Case 2: Naturally this is entirely different from having a PPU executable 
which links with with PPU shared object libraries (.so files) which are 
dynamically loaded either at load time or run time. Now within these PPU 
shared object libraries there maybe SPU executables embedded. We did not 
discuss this, and maybe that is what Arnd is talking about.

Again, greater minds need to respond. 

Brian Watt, Cell Software Development, Quasar Design Center
(512)823-6013, TL793-6013; FAX: Unknown
IBM Corporation, Div/7T, D/FSOA, B/906-5G015, M/S 906-5G015, 11501 Burnet 
Rd, Austin, TX 78758
Notes: Brian Watt/Austin/IBM at IBMUS, Internet: bwatt at us.ibm.com



maynardj at linux.vnet.ibm.com 
02/02/2007 01:35 PM
Please respond to
maynardj at linux.vnet.ibm.com


To
Arnd Bergmann <arnd at arndb.de>
cc
cbe-oss-dev at ozlabs.org, Alan Modra <amodra at au1.ibm.com>, Brian 
Watt/Austin/IBM at IBMUS, cel at linux.vnet.ibm.com
Subject
Support for embedded SPU ELF in dynamic libs






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 <><



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20070202/b68f90ed/attachment.htm>