Hi All, Op vr 20-04-2007, om 00:13 schreef Pedro Alves: > Danny Backx wrote: > > I've simplified the _eh_handler_ in > > src/newlib/newlib/libc/sys/wince/startup.c a bit, see attachment. > > > > This kicks out all the complicated handling in that function, and > > replaces it with a simple message box. > > > > > You're removing functionality. That function does a few things (there > are some log dumps that could 'go away'/'be ifdefs out'): > > - converts unaligned accesses to memcpy's. Questionable if this adds any > real value. Unaligned accesses should be fixed on the code that produces > them. Having a handler fix them hides a "bug", and makes programs run > slow. >
This has always been the case with ARM processors. Not signalling an unaligned word access will result in a rotated word-read. When Linux was ported to the ARM about 10 years ago or something the gcc compiler needed to take into account that packed structures should be read byte by byte. There is no real solution for this. The compiler can use padding if allowed to do so and makes sure all data will be word-aligned. Some programs rely on the 'x86' memory-access methods and will fail on ARM platforms. The most recent ARM gcc compilers will by default generate byte-by-byte memory access for packed structures. That should remove the necessity for an unaligned memory trap handler. My best guess is that there is something wrong with the configuration of the compiler of Danny. I have not seen this behaviour / problem in many years. There are very few exceptions here, the only one I can think of is by doing a cast without checking alignement first.This is not a failure of the compiler but a very wrong method of addressing memory or data by the programmer. The unalignment trap handler was a good intermediate way of solving the problem when most software was written in a 'quick-and-dirty' manner. Many patches have been submitted to remove incorrect usage/casting of data. There even are some gcc compiler flags specifically for fixing the alignment stuff on ARM platforms (not sure if they still exist) In short, it is too strong to say it is a bug. It actually is a feature of the ARM processor. Using a handler for unaligned memory access is the default ARM method and it helps to keep cross-platform compatibility. Speed is as always a problem when exception-handling needs to take over to ensure proper execution of programs. (All floating-point instructions will be handled by the undefined instruction handler... ) But you should keep in mind that many other processors have similar solutions to architectural problems. Some PowerPC processor have special handlers for instructions that are not built into the processor. These get emulated in some sort of firmware. Also intel processors have similar solutions. for some interesting reading: http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html http://www.aleph1.co.uk/node/294?PHPSESSID=af8de6d053f7342c8bfb27c86dee2817 both articles are very similar but the last one also adresses the debate that somehow still lingers about speed versus compatibility. > - implements very rudimentary support for SIGSEGV. I have not checked the code yet but alignment faults are not segmentation faults (data-aborts) i.i.r.c. and it generates SIGBUS under linux if configured to do so. Eventually the processor can be configured to ignore alignment errors which makes it more an OS related issue. Things get even more complicated when the alignment eror co-incides with a data-abort in the alignment handler.. > > > The downside is that the original (complicated) stuff is gone. I have no > > idea whether this actually worked. > > > > It does. At least it did many months ago. Not sure what was meant here but proper SEGV signals etc. would be very nice to have. > > > Is replacing this a good idea ? > > > > My test programs now show a dialog titled "WinCE Exception" and > > containing text such as > > ILLEGAL_INSTRUCTION > > Code C000001D > > Flags 0 > > (that's the test program that performs a floating point instruction for > > floating point hardware which isn't on my system), or > > ACCESS_VIOLATION > > Code C0000005 > > Flags 0 > > when trying to access a NULL pointer. > > > > Should cegcc apps really display dialogs like that? Maybe > they should do an fprintf (stderr, ...) instead. I'm thinking > of cegcc console apps over a telnet/ssh for instance. > > > Strangely, dividing by 0 doesn't cause such an exception. > > > > Are you sure the compiler didn't optimize the division into nan > or something else? > Try looking at the asm, building without optimization or > do something like: > > int main (int argc, char** argv) > { > return 5/(argc - 1); > } dividing is not an ARM instruction, it is done by the c library. any exceptions with arithmetic should never result in an SIGILL or SEGV. SIGFLOAT might happen when the division is done in floatingpoint. This behaviour is default for x86 processors but not on the ARM. Gcc for the ARM uses an implementation with 32 bit integers which may not result into an error at all! NAN therefore will never occur with integer division. (On x86 NAN may be a valid result however..) > > > I haven't tried this in mingw32ce yet, only in cegcc. > > > > The user should do it himself if he wants it in mingw32ce? > > (Any brave soul to implement proper ARM WinCE SEH > support on gcc ?) Forgive my lack of knowledge her but what is SEH? > > Cheers, > Pedro Alves > Jan Rinze. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
