RE: [ECOS] Possible bug in dbg-threads-syscall.c

["Patrick Doyle" <wpd at delcomsys dot com>]

> We haven't noticed that before, so I wonder what's different in your
> environment? Oh, perhaps it only happens if you're trying to debug before
> the kernel runs its constructors.

FWIW, my environment is the very minimal setup I could think of that
supported GDB stubs.  It is possible/likely that, in the process of copying
the mbx platform to my platform, I left something in or took something out
that, in normal situations, would not make sense to do.  The only packages
that I have are: CYGPKG_HAL_POWERPC, CYGPKG_HAL_POWERPC_PPC60x,
CYGPKG_HAL_POWERPC_TS6 (my target board), CYGPKG_HAL, and CYGPKG_INFRA.

Regardless, the end result was that 'dbg_thread_syscall()' was called at a
point when the value stored in 'dbg_syscall_ptr' was NULL.  So 'f =
*dbg_syscall_ptr' was whatever was stored at location 0 (in the interrupt
vectors) in my environment.  So '*f' was whatever function started at the
address indicated by the contents of address 0.

>
> > Anyway, here is my proposed patch, comments and feedback are definately
> > welcome :-)
>
> Looks fine, although I left in the check for *f being non-NULL too. It's
> good defensive programming anyway.
>
Great... sorry 'bout the lack of a ChangeLog entry.  I'll include one the
next time I submit a patch for review.

I am curious, however, if 'f' is a pointer to a function, what, exactly does
'*f' mean?  Normally, if 'iptr' is a pointer to an integer, '*iptr' means
the value stored at that location -- the integer itself.  Does that mean
that '*f', meaning the value stored at that location, is the entire
function?  (No).  More likely, it meanse the first byte/word/instruction of
the function.  Obviously, it is a construct that the language allows, but it
seems rather bizarre to me.

Thanks for the feedback.

--wpd