newlib: fputs aborts on ARM

[Tom Walsh]

Richard Earnshaw wrote:

>On Wed, 2005-11-16 at 08:10, Tom Walsh wrote:
>  
>
>>Well, I've run into a problem on this project.  Just to recap, I've 
>>compiled NewLib-1.13.0 with the following options:
>>
>>CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED 
>>-DINTEGER_ONLY -DPREFER_SIZE_OVER_SPEED
>>
>>I've done this to enable the various reent stubs.  The various stubs are 
>>defined in my application to interact with a FAT16 filesystem driver to 
>>an MMC card.  So far all the file stream functions are working: fopen(), 
>>fread(), etc..  What is a problem is that if a call to fputs() is made 
>>with an invalid file handle (NULL), then fvwrite() ultimately calls the 
>>malloc / free functions.  While there, data is allocated, then when the 
>>assigment of the buffer space is made to the file handle, the ARM 
>>processor triggers a Data Abort Exception (write to non-writeable space).
>>
>>At least that is how I followed the newlib code via the JTAG debugger.
>>
>>Normally, an invalid file handle would cause fputs() to return -1 (EOF) 
>>for operational error?  While in a perfect world, we would all write:
>>    
>>
>
>I've never come across any real system that would let you get away with
>passing an invalid file descriptor the the various file operations.  It
>simply won't work.  Consider the macro implementation of getc which
>directly manipulates the FILE structure inline.
>
>Normally you can just get away with testing that the file opened
>correctly and taking corrective action in that case.  The pedantic will
>check every file write/read and that is certainly good practice because,
>for example, continuting to hammer a full file system can cause all
>sorts of weirdness to happen[1].
>
>R.
>
>[1] I've seen a full OS brought to its knees by continuously trying to
>print on the console that some file system is full. This was caused by a
>program trying to generate an enormous log file with no error checking
>on the writes.
>  
>

<< ok, I see this is one of those mailing lists that you have to hit 
"reply all"  :-P >>

Oh, I'm not saying that newlib is not compliant, what my issue is that 
I'm planning to use it on a deeply embedded system (no human contact).  
My question is "why not".  For me, as an embedded designer, it is 
certainly better to have the library function call fail than to place 
the  processor into an impossible situation and it throws an exception?

The file streams are to be used with an MMC card subsystem,  it is 
possible that the card would be removed during use (suddenly 
disappear).  You know end-users, tell them not to do  something in the 
manual and they never read the manual.  While the behavior of forcing 
the CPU into a fault situation may work on "normal" system, it is not 
very hospitable to embedded systems.

What deeply concerns me, is that since a common-sense situation of 
gracefully returning both an errno + EOF from a bad call to the library 
is not present in the file stream layer.  That where the file streams 
code relies upon fatally aborting the process(or), what other problems 
might be lurking in the library?  I'm concerned as it may be indicative 
of other issues I may not be aware of.

I chose the newlib as it was LGPL and it was said that it was for 
embedded / small footprint devices.


Regards,

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------