This is the mail archive of the ecos-discuss@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: printf problem in twothreads sample


On Sat, 2003-06-28 at 06:30, Andrew Lunn wrote:
> > When I step through the program, the failure is in vfnprintf.cxx,
> > function vfnprintf().  After parsing and finding the "%" in the format
> > string, a line in the assembler code in vfnprintf() produces signal
> > SIGILL, Illegal instruction.  I wonder if this is a problem with code
> > over-optimization?  I also wonder if the problem I'm seeing with printf
> > is a symptom of some larger problem with the eCos code I generated for
> > this platform with the config tool?            
> 
> I would check to see if the instruction causing the problem is
> actually illegal for your processor. ie is gcc using an SH4
> instruction even though you are on an SH3 processor. 
> 
>             Andrew

Andrew,

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?  

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. 
              

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


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