profiling on sh

[Kris Warkentin]

So it looks like I have two options then - get the code to call mcount()
working (we already have an implementation of mcount() for sh) or, at the
start of profiled code for sh, just insert an interrupt handler.  The QNX
Neutrino context switch for handlers is pretty quick so that might be a
viable option.  Perhaps I'll try to get the regular call working first and
then the trap and see if there are any performance differences.

So, it looks like my only problem left is how to get the 'label: .long
mcount' inserted in a sensible way.  Thank you very much for all the great
help,

Cheers,

Kris

----- Original Message -----
From: "Alexandre Oliva" <aoliva@redhat.com>
To: <kewarken@qnx.com>
Cc: "Stephen Clarke" <Stephen.Clarke@st.com>; <gcc@gcc.gnu.org>
Sent: Saturday, March 16, 2002 1:16 PM
Subject: Re: profiling on sh


On Mar 16, 2002, kewarken@qnx.com wrote:

> That was part of my original question.  What exactly is the trapa
> supposed to be doing?

It issues an exception, whose handler is presumably set by whatever
mini-OS/program loader this was designed for, this being the profiling
API of such mini-OS.

> I don't see a handler for that anywhere or know of how to set it up.

Me neither, I'm afraid.  As far as I'm concerned, we don't have
profiling support on the SH.  I wouldn't mind if someone revamped it
to put it more in line with other implementations of profiling.  But
it would be best to get clearance with Jörn too, since I think he was
the last person who touched that code for real, back in 1997 (which
predates my involvement with the SH by 3 years :-).  Jörn?

> I'd love to just be able to set trapa #33 to call mcount but I don't
> know where that would be done...OS level or code level.

OS level, for sure.  It's the OS that's supposed to manipulate
interrupt handlers.  As for how to set up such handlers, you may want
to have a look at the `Exceptions' section in one of the SH
programming manuals.

I'm pretty sure using a trap is the most efficient solution in terms
of code size, but I'm not sure it's as efficient in terms of not
affecting the performance of the running code.  I'd expect traps to be
relatively expensive operations.

--
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer