This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debug improvement


On Mon, 2003-02-10 at 14:42, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > While debugging some thread problems recently, I turned on asserts and 
> > thread stack checking only to find the results less than useful.  Yes, 
> > the checking code detected the error (most times), but I was unable to 
> > get useful information from GDB (I set a breakpoint at 
> > cyg_assert_fail).  This was because the stack had been trashed severely.
> 
> Although if the stack is that dead, it's not clear a diag_printf would 
> work any better!
> 

Agreed.  The problem with GDB was that it couldn't give me any useful
thread or register info when it got into this state, but the dump was
still helpful.

> > What I ended up doing was augmenting the stack check to provide a simple
> > dump when an error was detected (along with the assert).  By being able 
> > to see the dump, I was able to get more information and move along.
> > 
> > My question is: what do y'all think of making such a change permanent.  
> > I know that we've tried to keep most of these interfaces pretty pristine
> > (no prints, no dumps, etc), but what's there didn't help me and I'm sure
> > that others in the world (certainly ones with less experience with eCos 
> > than I) would have been "stuck" with the existing support.
> 
> I think it's fine personally, although it might be a fraction clearer by 
> removing the subsequent CYG_ASSERT and replacing it with a CYG_FAIL within 
> the if block. And you may as well do the same for top[i] for symmetry. And 
> maybe refer to it as "word at location %d in:\n", i*sizeof(cyg_uint32) 
> again for clarity.
> 
> As long as CYGNUM_KERNEL_THREADS_STACK_CHECK_DATA_SIZE is always going to 
> be a smallish number like 32 anyway (otherwise the output might be 
> unhelpfully long), but I'm sure it will.
> 

Agreed, thanks.

-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]