Re: Hitachi djprobe mechanism

[Mathieu Lacage <Mathieu.Lacage@sophia.inria.fr>]

On Tue, 2005-08-02 at 12:22 -0400, Karim Yaghmour wrote:

> In as far as the insertions do not cross basic-block boundaries, then
> this would seem to hold, and it would seem to solve the main issues I
> had with this approach. I haven't really looked at the implications of
> this entirely, and there may be some corner cases still (like copy_to_
> user() and the other CPU-related stuff) but it's certainly a refreshing
> take on things.
> 
> Clearly then it would become necessary to have a basic block analyzer
> that runs at least once prior to inserting any such probes. It would

Yes. I might give a try at writing a real one sometime soon. This is
just too interesting for me not to pursue it a bit further :)

> certainly be interesting to see what the compiler reports in terms of
> basic block sizes.
> 
> BTW, looking rapidely at your script, it doesn't seem to look for "call".

Yes, I assumed that all "call"s return someday (which is obviously wrong
for a few prominent functions in the kernel) but I did not really think
about the issue of EIPs located on the stack when I wrote that script.

I am also pretty sure that there are a few bugs in this code, most
notably one which you will get if you see the "old bb empty" message. I
have not yet figured out how this code path can be triggered (it
shouldn't).

If you take the constraint of call-pushed EIPs on the stack into
account, you need to change the script to split the bbs right after
calls. I will do this tonight and see if it changes the results notably.

> Maybe someone should try compiling the kernel with -fprofile-arcs and
> -ftest-coverage to get the .bb and .bbg files, and run an analysis based
> on those files.

Do you know of any documentation on the format of these files other than
the gcc source code ? I must confess that I did not know these options
actually generated a dump of the basic blocks but now that I think about
it, it is quite obvious...

Mathieu
--