This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: printf problem in twothreads sample
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Rod Campbell <rodc at sigmaelectronics dot com>
- Cc: ecos-discuss <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 02 Jul 2003 04:14:38 +0100
- Subject: Re: [ECOS] printf problem in twothreads sample
- References: <1056752597.29927.135.camel@rodlinux> <20030628103016.GB744@biferten.ma.tech.ascom.ch> <1056980033.7375.32.camel@rodlinux>
Rod Campbell wrote:
Thanks for the reply. I looked at the assembler code and I see no
problem with it that should result in an illegal instruction exception.
I then changed to use a version of redboot that I created for startup
debugging - it has some extra assembler code at the various exception
vectors that wiggle some unused processor port pins to communicate
exception data to a logic analyzer.
When I loaded Twothreads.c and single-stepped, my logic analyzer
captured the TRAP exception that GDB/redboot sets for this purpose (as
expected). But when I got to the point where vfnprintf() has its
problems (when processing the "%" in the format string), instead of
getting the SIGILL, the debugger just stopped responding and I saw the
same stream of ascii zeros sent to the debug console window as before.
The logic analyzer did not trigger - which means there was no exception
during this time.
Since I was using a modified redboot, the locations of various routines
had possibly changed from my previos tests. I wonder if there is a bad
pointer somewhere in the code shared between RedBoot and my app -
possibly related to the VVT?
Maybe memory could have gotten corrupted somehow. Have you actually
disassembled the contents of memory at the point of the SIGILL using GDB?
Does it SIGILL at the same place each time?
I'd also try compiling without optimization, just in case (and do be sure
the compiler is being invoked with -m3, not -m4 or -m4-nofpu) since your
board is an SH3 I believe.
I also came across a previous post in this archive - "printf in
Redboot/GDB" of 10 Oct 2002, where Gary Thomas states that "printf()
uses higher level functionality which is not enabled in the simple
ROM-based RedBoot" (and I AM using a ROM-based Redboot). However my
symptoms differ from that post - printf DOES work for me if the data is
static. Is Gary's statement true for my case? I don't want to ignore a
problem that may be a symptom of a larger problem. Thanks.
He meant using printf *in* RedBoot, as opposed to in an application loaded
by RedBoot.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss