<br><font size=2 face="sans-serif">All,</font>
<br>
<br><font size=2 face="sans-serif">Just to make sure, I'm no expert in
all this.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Again, greater minds need to respond.
</font>
<br><font size=2 face="sans-serif"><br>
Brian Watt, Cell Software Development, Quasar Design Center<br>
(512)823-6013, TL793-6013; FAX: Unknown<br>
IBM Corporation, Div/7T, D/FSOA, B/906-5G015, M/S 906-5G015, 11501 Burnet
Rd, Austin, TX 78758<br>
Notes: Brian Watt/Austin/IBM@IBMUS, Internet: bwatt@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>maynardj@linux.vnet.ibm.com</b>
</font>
<p><font size=1 face="sans-serif">02/02/2007 01:35 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
maynardj@linux.vnet.ibm.com</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Arnd Bergmann <arnd@arndb.de></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">cbe-oss-dev@ozlabs.org, Alan Modra <amodra@au1.ibm.com>,
Brian Watt/Austin/IBM@IBMUS, cel@linux.vnet.ibm.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Support for embedded SPU ELF in dynamic
libs</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Arnd,<br>
In one of the review comments to our OProfile-Cell SPU profiling patch
<br>
(see below), you mentioned that we may have to handle "an embedded
spu <br>
ELF file in a shared library object". You state that our current
<br>
OProfile implementation does not support such a model. That's a true
<br>
statement, since we were not aware of a requirement to support such a <br>
model. I gave Brian Watt a call to ask what he knew about this, and
<br>
he's not aware of anyone who's attempted to do this and wasn't sure if
<br>
it's a supported model. He suggested I ask Alan Modra, who I put
on cc.<br>
<br>
Alan, can you shed any light on this topic?<br>
<br>
Thanks.<br>
<br>
-Maynard<br>
<br>
Arnd Bergmann wrote:<br>
<br>
> On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:<br>
> <br>
>>Arnd Bergmann wrote:<br>
> <br>
> <br>
>>>I don't get it. What is the app_dcookie used for? If the spu
binary is<br>
>>>embedded into a library, you are still missing the dcookie
to that .so file,<br>
>>>because you return only an offset.<br>
>><br>
>>For embedded SPU app, the post-processing tool opens the PPE binary
app <br>
>>file and obtains the SPU ELF embedded thereine, and from that,
we obtain <br>
>>the name of the SPU binary. Also, the app name is included
in the <br>
>>report, along with the SPU binary filename, if the report contains
<br>
>>samples from more than one application.<br>
> <br>
> <br>
> That's not what I meant. If you have an embedded spu ELF file in a
shared<br>
> library object, you end up recording the file of the main PPE binary,
and<br>
> the offset of the SPU ELF inside of the .so file, but not the name
of the<br>
> .so file itself.<br>
> <br>
> You also say that the you record the name of the application on purpose
for<br>
> separate SPU ELF files. My assumption was that this is not necessary,
but<br>
> I don't know much about that aspect of oprofile. My feeling is that
the<br>
> samples for an external SPU ELF file should be handled the same way
that<br>
> oprofile handles events in shared libraries on the PPU (e.g. in libc.so).<br>
> <br>
> Arnd
<><<br>
<br>
<br>
</font></tt>
<br>