public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] profiler & memory leak detector
@ 2002-07-22 12:27 NavEcos
  2002-07-22 13:15 ` benny
  0 siblings, 1 reply; 8+ messages in thread
From: NavEcos @ 2002-07-22 12:27 UTC (permalink / raw)
  To: ecos-discuss

Try as I may, I cannot post this to the ecos-devel list, although I am
signed up for it, so I'm going to post it here in the discussion list.

Has or does anybody use vxWorks?

If you have, you may have used their profiler.  I have a very simple
profiler that I can make available for the x86 PC target.  I would like to
know if there would be any interest in making such a beast available in the
main tree?  It requires a modification in the kernel in vectors.S.
Basically, I just detect interrupts with vector 0x20 (the 10 msec interrupt)
and record the last function the program was in when the periodic system
tick fired.  I know this has some problems, namely anything that has a delay
is tied to the system tick, but for stressed systems it gives a pretty
accurate view of what functions you have to streamline.

VxWorks also has a tool called memtool.  It just detects which functions
(and if memory serves tasks) allocate and dealloc memory and in which heap.
This is useful for detecting memory leaks although not extremely useful.  I
don't have a similar tool, but I can make one.

Is there any interest in putting these into the main tree?  Putting in HOOKS
to do it is very easy, and I would like to do that if there is any interest
in incorporating it into the main tree.

The profiler is very architecture dependant so I need help making that work
for other platforms than x86 PC.

-Rich


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [ECOS] profiler & memory leak detector
  2002-07-22 12:27 [ECOS] profiler & memory leak detector NavEcos
@ 2002-07-22 13:15 ` benny
  2002-07-22 14:01   ` NavEcos
  0 siblings, 1 reply; 8+ messages in thread
From: benny @ 2002-07-22 13:15 UTC (permalink / raw)
  To: NavEcos, ecos-discuss

I guess such tool (similar to VxWorks SPY) would be great.
It actually works "per task" so after a while one can get a list of
task CPU consumption. Just the timer needs to be with the higher resolution
(some spare timer?)
-Benny

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> Sent: Monday, July 22, 2002 1:32 PM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] profiler & memory leak detector
>
>
> Try as I may, I cannot post this to the ecos-devel list, although I am
> signed up for it, so I'm going to post it here in the discussion list.
>
> Has or does anybody use vxWorks?
>
> If you have, you may have used their profiler.  I have a very simple
> profiler that I can make available for the x86 PC target.  I would like to
> know if there would be any interest in making such a beast
> available in the
> main tree?  It requires a modification in the kernel in vectors.S.
> Basically, I just detect interrupts with vector 0x20 (the 10 msec
> interrupt)
> and record the last function the program was in when the periodic system
> tick fired.  I know this has some problems, namely anything that
> has a delay
> is tied to the system tick, but for stressed systems it gives a pretty
> accurate view of what functions you have to streamline.
>
> VxWorks also has a tool called memtool.  It just detects which functions
> (and if memory serves tasks) allocate and dealloc memory and in
> which heap.
> This is useful for detecting memory leaks although not extremely
> useful.  I
> don't have a similar tool, but I can make one.
>
> Is there any interest in putting these into the main tree?
> Putting in HOOKS
> to do it is very easy, and I would like to do that if there is
> any interest
> in incorporating it into the main tree.
>
> The profiler is very architecture dependant so I need help making
> that work
> for other platforms than x86 PC.
>
> -Rich
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] profiler & memory leak detector
  2002-07-22 13:15 ` benny
@ 2002-07-22 14:01   ` NavEcos
  2002-07-22 14:14     ` [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Tim Drury
  2002-07-23  0:41     ` [ECOS] profiler & memory leak detector Martin Buck
  0 siblings, 2 replies; 8+ messages in thread
From: NavEcos @ 2002-07-22 14:01 UTC (permalink / raw)
  To: benny, benny, ecos-discuss

Doing it per task is a little more work, I don't see any way to
determine which task I am in when I'm in the __default_exception_vsr
routine (system tick interrupt - actually this is the interrupt
for everything I think for the i386).  I don't think it should be
hard to determine which task was executing when the interrupt
happened, but I hadn't planned on doing it.  I bet it can be
done with a global variables - does anybody know if this is true
or not, and if it's true - how ?

As to doing it with another interrupt with a higher frequency,
I agree, but some embedded systems may not have a spare
timer, so I think a "fall back" should be the system tick.  What
would be ideal is an interrupt that has a bit of jitter with a
frequency higher than the system tick.  I am pretty sure that
vxWorks does it based off from the system tick, but I am not
100% certain.

My version also requires : Linux, and a network connection and
binutils (i.e. readelf and the sort command) since my version is
a HACK and makes use of external programs.

Many thanks,
-Rich

P.S. Does anybody know what is wrong with the ecos-devel list? 
Everything I send there is returned as a fatal error.

On Monday 22 July 2002 02:14 pm, benny wrote:
> I guess such tool (similar to VxWorks SPY) would be great.
> It actually works "per task" so after a while one can get a list of
> task CPU consumption. Just the timer needs to be with the higher resolution
> (some spare timer?)
> -Benny
>
> > -----Original Message-----
> > From: ecos-discuss-owner@sources.redhat.com
> > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > Sent: Monday, July 22, 2002 1:32 PM
> > To: ecos-discuss@sources.redhat.com
> > Subject: [ECOS] profiler & memory leak detector
> >
> >
> > Try as I may, I cannot post this to the ecos-devel list, although I am
> > signed up for it, so I'm going to post it here in the discussion list.
> >
> > Has or does anybody use vxWorks?
> >
> > If you have, you may have used their profiler.  I have a very simple
> > profiler that I can make available for the x86 PC target.  I would like
> > to know if there would be any interest in making such a beast
> > available in the
> > main tree?  It requires a modification in the kernel in vectors.S.
> > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > interrupt)
> > and record the last function the program was in when the periodic system
> > tick fired.  I know this has some problems, namely anything that
> > has a delay
> > is tied to the system tick, but for stressed systems it gives a pretty
> > accurate view of what functions you have to streamline.
> >
> > VxWorks also has a tool called memtool.  It just detects which functions
> > (and if memory serves tasks) allocate and dealloc memory and in
> > which heap.
> > This is useful for detecting memory leaks although not extremely
> > useful.  I
> > don't have a similar tool, but I can make one.
> >
> > Is there any interest in putting these into the main tree?
> > Putting in HOOKS
> > to do it is very easy, and I would like to do that if there is
> > any interest
> > in incorporating it into the main tree.
> >
> > The profiler is very architecture dependant so I need help making
> > that work
> > for other platforms than x86 PC.
> >
> > -Rich
> >
> >
> > --
> > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector)
  2002-07-22 14:01   ` NavEcos
@ 2002-07-22 14:14     ` Tim Drury
  2002-07-22 14:20       ` [ECOS] " NavEcos
  2002-07-22 14:21       ` [ECOS] " Gary Thomas
  2002-07-23  0:41     ` [ECOS] profiler & memory leak detector Martin Buck
  1 sibling, 2 replies; 8+ messages in thread
From: Tim Drury @ 2002-07-22 14:14 UTC (permalink / raw)
  To: ecos, NavEcos, ecos-discuss


In the email sent below, why does the From: line appear to be:

From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>

Which appears to be using my siliconmotorsports.com domain name
with a strange subdomain and an invalid user id?  Did everyone else
see this address or did they get something else munged to look like
it came from their address?

No other email from the ecos lists appears to have done this.  Did
the listserv software do this, or did the poster do this?

-tim drury

On Monday 22 July 2002 05:05 pm, NavEcos wrote:
> Doing it per task is a little more work, I don't see any way to
> determine which task I am in when I'm in the __default_exception_vsr
> routine (system tick interrupt - actually this is the interrupt
> for everything I think for the i386).  I don't think it should be
> hard to determine which task was executing when the interrupt
> happened, but I hadn't planned on doing it.  I bet it can be
> done with a global variables - does anybody know if this is true
> or not, and if it's true - how ?
>
> As to doing it with another interrupt with a higher frequency,
> I agree, but some embedded systems may not have a spare
> timer, so I think a "fall back" should be the system tick.  What
> would be ideal is an interrupt that has a bit of jitter with a
> frequency higher than the system tick.  I am pretty sure that
> vxWorks does it based off from the system tick, but I am not
> 100% certain.
>
> My version also requires : Linux, and a network connection and
> binutils (i.e. readelf and the sort command) since my version is
> a HACK and makes use of external programs.
>
> Many thanks,
> -Rich
>
> P.S. Does anybody know what is wrong with the ecos-devel list?
> Everything I send there is returned as a fatal error.
>
> On Monday 22 July 2002 02:14 pm, benny wrote:
> > I guess such tool (similar to VxWorks SPY) would be great.
> > It actually works "per task" so after a while one can get a list of
> > task CPU consumption. Just the timer needs to be with the higher
> > resolution (some spare timer?)
> > -Benny
> >
> > > -----Original Message-----
> > > From: ecos-discuss-owner@sources.redhat.com
> > > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > > Sent: Monday, July 22, 2002 1:32 PM
> > > To: ecos-discuss@sources.redhat.com
> > > Subject: [ECOS] profiler & memory leak detector
> > >
> > >
> > > Try as I may, I cannot post this to the ecos-devel list, although I am
> > > signed up for it, so I'm going to post it here in the discussion list.
> > >
> > > Has or does anybody use vxWorks?
> > >
> > > If you have, you may have used their profiler.  I have a very simple
> > > profiler that I can make available for the x86 PC target.  I would like
> > > to know if there would be any interest in making such a beast
> > > available in the
> > > main tree?  It requires a modification in the kernel in vectors.S.
> > > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > > interrupt)
> > > and record the last function the program was in when the periodic
> > > system tick fired.  I know this has some problems, namely anything that
> > > has a delay
> > > is tied to the system tick, but for stressed systems it gives a pretty
> > > accurate view of what functions you have to streamline.
> > >
> > > VxWorks also has a tool called memtool.  It just detects which
> > > functions (and if memory serves tasks) allocate and dealloc memory and
> > > in which heap.
> > > This is useful for detecting memory leaks although not extremely
> > > useful.  I
> > > don't have a similar tool, but I can make one.
> > >
> > > Is there any interest in putting these into the main tree?
> > > Putting in HOOKS
> > > to do it is very easy, and I would like to do that if there is
> > > any interest
> > > in incorporating it into the main tree.
> > >
> > > The profiler is very architecture dependant so I need help making
> > > that work
> > > for other platforms than x86 PC.
> > >
> > > -Rich
> > >
> > >
> > > --
> > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ECOS] Re: OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector)
  2002-07-22 14:14     ` [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Tim Drury
@ 2002-07-22 14:20       ` NavEcos
  2002-07-22 14:21       ` [ECOS] " Gary Thomas
  1 sibling, 0 replies; 8+ messages in thread
From: NavEcos @ 2002-07-22 14:20 UTC (permalink / raw)
  To: Tim Drury, ecos, NavEcos, ecos-discuss

On Monday 22 July 2002 02:12 pm, Tim Drury wrote:
> In the email sent below, why does the From: line appear to be:
>
> From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>

Actually it's <ecos2@c1830598-a>

This is because I just setup a new account under KMail, and I
muffed the setup, the reply-to is correct but the from is
incorrect.

c1830598-a.home.com WAS my fully qualified domain name
before @Home went belly up.  Now it's attbi.com.

Anyhow, my address is and should appear to be:
ecos at navosha dot com.

My apologies. :-/

-Rich

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector)
  2002-07-22 14:14     ` [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Tim Drury
  2002-07-22 14:20       ` [ECOS] " NavEcos
@ 2002-07-22 14:21       ` Gary Thomas
  1 sibling, 0 replies; 8+ messages in thread
From: Gary Thomas @ 2002-07-22 14:21 UTC (permalink / raw)
  To: Tim Drury; +Cc: eCos Discussion

On Mon, 2002-07-22 at 15:12, Tim Drury wrote:
> 
> In the email sent below, why does the From: line appear to be:
> 
> From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>
> 
> Which appears to be using my siliconmotorsports.com domain name
> with a strange subdomain and an invalid user id?  Did everyone else
> see this address or did they get something else munged to look like
> it came from their address?
> 

They've done something magic - for me that message said:
  From: NavEcos <ecos2@c1830598-a.chez-thomas.org>

> No other email from the ecos lists appears to have done this.  Did
> the listserv software do this, or did the poster do this?
> 
> -tim drury
> 
> On Monday 22 July 2002 05:05 pm, NavEcos wrote:
> > Doing it per task is a little more work, I don't see any way to
> > determine which task I am in when I'm in the __default_exception_vsr
> > routine (system tick interrupt - actually this is the interrupt
> > for everything I think for the i386).  I don't think it should be
> > hard to determine which task was executing when the interrupt
> > happened, but I hadn't planned on doing it.  I bet it can be
> > done with a global variables - does anybody know if this is true
> > or not, and if it's true - how ?
> >
> > As to doing it with another interrupt with a higher frequency,
> > I agree, but some embedded systems may not have a spare
> > timer, so I think a "fall back" should be the system tick.  What
> > would be ideal is an interrupt that has a bit of jitter with a
> > frequency higher than the system tick.  I am pretty sure that
> > vxWorks does it based off from the system tick, but I am not
> > 100% certain.
> >
> > My version also requires : Linux, and a network connection and
> > binutils (i.e. readelf and the sort command) since my version is
> > a HACK and makes use of external programs.
> >
> > Many thanks,
> > -Rich
> >
> > P.S. Does anybody know what is wrong with the ecos-devel list?
> > Everything I send there is returned as a fatal error.
> >
> > On Monday 22 July 2002 02:14 pm, benny wrote:
> > > I guess such tool (similar to VxWorks SPY) would be great.
> > > It actually works "per task" so after a while one can get a list of
> > > task CPU consumption. Just the timer needs to be with the higher
> > > resolution (some spare timer?)
> > > -Benny
> > >
> > > > -----Original Message-----
> > > > From: ecos-discuss-owner@sources.redhat.com
> > > > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > > > Sent: Monday, July 22, 2002 1:32 PM
> > > > To: ecos-discuss@sources.redhat.com
> > > > Subject: [ECOS] profiler & memory leak detector
> > > >
> > > >
> > > > Try as I may, I cannot post this to the ecos-devel list, although I am
> > > > signed up for it, so I'm going to post it here in the discussion list.
> > > >
> > > > Has or does anybody use vxWorks?
> > > >
> > > > If you have, you may have used their profiler.  I have a very simple
> > > > profiler that I can make available for the x86 PC target.  I would like
> > > > to know if there would be any interest in making such a beast
> > > > available in the
> > > > main tree?  It requires a modification in the kernel in vectors.S.
> > > > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > > > interrupt)
> > > > and record the last function the program was in when the periodic
> > > > system tick fired.  I know this has some problems, namely anything that
> > > > has a delay
> > > > is tied to the system tick, but for stressed systems it gives a pretty
> > > > accurate view of what functions you have to streamline.
> > > >
> > > > VxWorks also has a tool called memtool.  It just detects which
> > > > functions (and if memory serves tasks) allocate and dealloc memory and
> > > > in which heap.
> > > > This is useful for detecting memory leaks although not extremely
> > > > useful.  I
> > > > don't have a similar tool, but I can make one.
> > > >
> > > > Is there any interest in putting these into the main tree?
> > > > Putting in HOOKS
> > > > to do it is very easy, and I would like to do that if there is
> > > > any interest
> > > > in incorporating it into the main tree.
> > > >
> > > > The profiler is very architecture dependant so I need help making
> > > > that work
> > > > for other platforms than x86 PC.
> > > >
> > > > -Rich
> > > >
> > > >
> > > > --
> > > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [ECOS] profiler & memory leak detector
  2002-07-22 14:01   ` NavEcos
  2002-07-22 14:14     ` [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Tim Drury
@ 2002-07-23  0:41     ` Martin Buck
  1 sibling, 0 replies; 8+ messages in thread
From: Martin Buck @ 2002-07-23  0:41 UTC (permalink / raw)
  To: ecos-discuss

NavEcos wrote:
> for everything I think for the i386).  I don't think it should be
> hard to determine which task was executing when the interrupt
> happened, but I hadn't planned on doing it.  I bet it can be
> done with a global variables - does anybody know if this is true
> or not, and if it's true - how ?

It *should* be safe to call cyg_thread_self() from anywhere - it just
reads a static variable. Of course, that's not guaranteed, but I guess a
profiler is always a bit messy and that hack worked fine for the simple
thread profiler I once implemented.

> My version also requires : Linux, and a network connection and
> binutils (i.e. readelf and the sort command) since my version is
> a HACK and makes use of external programs.

Which is fine, since that's exactly the Unix way to do it. :-)

Martin

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector)
@ 2002-07-22 14:18 Dan Conti
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Conti @ 2002-07-22 14:18 UTC (permalink / raw)
  To: ecos-discuss

For me it's just ecos2@c1830598-a

I'm guessing either your mail client or your mail server decided to append your domain name to the email address when it noticed it wasn't a complete email address.


-----Original Message-----
From: Tim Drury [mailto:tdrury@siliconmotorsports.com]
Sent: Monday, July 22, 2002 2:12 PM
To: ecos@navosha.com; NavEcos; ecos-discuss@sources.redhat.com
Subject: [ECOS] OT: Strange sender address (was Re: [ECOS] profiler &
memory leak detector)



In the email sent below, why does the From: line appear to be:

From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>

Which appears to be using my siliconmotorsports.com domain name
with a strange subdomain and an invalid user id?  Did everyone else
see this address or did they get something else munged to look like
it came from their address?

No other email from the ecos lists appears to have done this.  Did
the listserv software do this, or did the poster do this?

-tim drury

On Monday 22 July 2002 05:05 pm, NavEcos wrote:
> Doing it per task is a little more work, I don't see any way to
> determine which task I am in when I'm in the __default_exception_vsr
> routine (system tick interrupt - actually this is the interrupt
> for everything I think for the i386).  I don't think it should be
> hard to determine which task was executing when the interrupt
> happened, but I hadn't planned on doing it.  I bet it can be
> done with a global variables - does anybody know if this is true
> or not, and if it's true - how ?
>
> As to doing it with another interrupt with a higher frequency,
> I agree, but some embedded systems may not have a spare
> timer, so I think a "fall back" should be the system tick.  What
> would be ideal is an interrupt that has a bit of jitter with a
> frequency higher than the system tick.  I am pretty sure that
> vxWorks does it based off from the system tick, but I am not
> 100% certain.
>
> My version also requires : Linux, and a network connection and
> binutils (i.e. readelf and the sort command) since my version is
> a HACK and makes use of external programs.
>
> Many thanks,
> -Rich
>
> P.S. Does anybody know what is wrong with the ecos-devel list?
> Everything I send there is returned as a fatal error.
>
> On Monday 22 July 2002 02:14 pm, benny wrote:
> > I guess such tool (similar to VxWorks SPY) would be great.
> > It actually works "per task" so after a while one can get a list of
> > task CPU consumption. Just the timer needs to be with the higher
> > resolution (some spare timer?)
> > -Benny
> >
> > > -----Original Message-----
> > > From: ecos-discuss-owner@sources.redhat.com
> > > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > > Sent: Monday, July 22, 2002 1:32 PM
> > > To: ecos-discuss@sources.redhat.com
> > > Subject: [ECOS] profiler & memory leak detector
> > >
> > >
> > > Try as I may, I cannot post this to the ecos-devel list, although I am
> > > signed up for it, so I'm going to post it here in the discussion list.
> > >
> > > Has or does anybody use vxWorks?
> > >
> > > If you have, you may have used their profiler.  I have a very simple
> > > profiler that I can make available for the x86 PC target.  I would like
> > > to know if there would be any interest in making such a beast
> > > available in the
> > > main tree?  It requires a modification in the kernel in vectors.S.
> > > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > > interrupt)
> > > and record the last function the program was in when the periodic
> > > system tick fired.  I know this has some problems, namely anything that
> > > has a delay
> > > is tied to the system tick, but for stressed systems it gives a pretty
> > > accurate view of what functions you have to streamline.
> > >
> > > VxWorks also has a tool called memtool.  It just detects which
> > > functions (and if memory serves tasks) allocate and dealloc memory and
> > > in which heap.
> > > This is useful for detecting memory leaks although not extremely
> > > useful.  I
> > > don't have a similar tool, but I can make one.
> > >
> > > Is there any interest in putting these into the main tree?
> > > Putting in HOOKS
> > > to do it is very easy, and I would like to do that if there is
> > > any interest
> > > in incorporating it into the main tree.
> > >
> > > The profiler is very architecture dependant so I need help making
> > > that work
> > > for other platforms than x86 PC.
> > >
> > > -Rich
> > >
> > >
> > > --
> > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-07-23  7:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-22 12:27 [ECOS] profiler & memory leak detector NavEcos
2002-07-22 13:15 ` benny
2002-07-22 14:01   ` NavEcos
2002-07-22 14:14     ` [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Tim Drury
2002-07-22 14:20       ` [ECOS] " NavEcos
2002-07-22 14:21       ` [ECOS] " Gary Thomas
2002-07-23  0:41     ` [ECOS] profiler & memory leak detector Martin Buck
2002-07-22 14:18 [ECOS] OT: Strange sender address (was Re: [ECOS] profiler & memory leak detector) Dan Conti

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).