Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "John Zoidberg" <the.real.doctor.zoidberg@gmail.com>
To: "mathieu lacage" <Mathieu.Lacage@sophia.inria.fr>,
	 	"Andrew STUBBS" <andrew.stubbs@st.com>,
	gdb@sourceware.org
Subject: Re: Log every call and exit in embedded system
Date: Tue, 27 Mar 2007 11:07:00 -0000	[thread overview]
Message-ID: <adbca6b50703270407qf1be45cr29c39df513c779fe@mail.gmail.com> (raw)
In-Reply-To: <1174904601.2370.5.camel@mathieu>

On 3/26/07, mathieu lacage <Mathieu.Lacage@sophia.inria.fr> wrote:
> On Mon, 2007-03-26 at 11:03 +0100, Andrew STUBBS wrote:
> > John Zoidberg wrote:
> > > Is this the only way? Can anyone give me any suggestions or hints?
> >
> > The way profiling works is that the compiler inserts a call to a
> > function (mcount?) at each function call (*). I'm not sure on the
> > precise rules for this, or whether it varies between target types, but
> > these are details that you can certainly dig up from somewhere.
>
> with gcc, -finstrument-functions
>
> generates calls to:
>
>          void __cyg_profile_func_enter (void *this_fn,
>                                          void *call_site);
>           void __cyg_profile_func_exit  (void *this_fn,
>                                          void *call_site);

I'll investigate this further.
With embedded systems there are always issues... but I think I can use
these functions to log to a buffer the address of the called functions
(and then look them up).

> > If you provide your own implementation for this function then it can do
> > anything you like. Printing a call graph at run time should not be too
> > hard (though it may be tricky if your print mechanisms are also
> > instrumented).
>
> I actually wrote a tool to do this: http://cutebugs.net/bozo-profiler/
>
> Mathieu

Your tool seems very interesting, it's unfortunate it's not ready for
embedded systems.
On the documentation you mention malloc, but some embedded systems
don't have the code for malloc. Moreover, no embedded system uses
glibc, it uses newlib, uclib, and others... this means that the code
that is linked may not have the support for it (i.e. there are missing
functions).
There is the issue of the target code (the part that is linked to the
application) must be compiled with the corresponding GCC (for the
target system).
And besides all this, there is the issue of where to log the
information or how to send it.


Thanks!


  reply	other threads:[~2007-03-27 11:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-24 20:05 John Zoidberg
2007-03-24 22:20 ` Daniel Jacobowitz
2007-03-26 10:04 ` Andrew STUBBS
2007-03-26 10:23   ` mathieu lacage
2007-03-27 11:07     ` John Zoidberg [this message]
2007-03-27 11:56       ` Mathieu Lacage
2007-03-26 21:33 ` Michael Snyder
2007-03-27  9:56   ` John Zoidberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adbca6b50703270407qf1be45cr29c39df513c779fe@mail.gmail.com \
    --to=the.real.doctor.zoidberg@gmail.com \
    --cc=Mathieu.Lacage@sophia.inria.fr \
    --cc=andrew.stubbs@st.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox