Op vr 20-04-2007, om 02:16 schreef Pedro Alves:
> Jan Rinze wrote:
>
> > 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.
> >
>
> Yes there is. Fix the software that is making the problem trigger.
> 10 years ago, having a handler was the only way to go, but nowadays
> I guess most problems are solved now.
> The most problematic constructs where things like:
>
> char* buf = <...>;
> *(unsigned long*)buf = 0xfeedf00d;
>
> where buf may not be 32-bit aligned. The portable way to fix this
> is to use memcpy. (The compiler is allowed to inline the memcpy.)
>
> I'm not advocating for removing
> the handler, though.
>
On x86 the above is perfectly valid and therefore gcc does a 4 byte
write. This should not be a memcpy however unless the data is already
somewhere in the memory. Any long variable should be able to be written
anywhere in memory.. the problem is that when the data is only in a
temporary register things go wrong. Any other assingment will be just a
memcpy anyway.. This means that the programmer should take extra care
about how to interact directly with memory. For people used to
programming on x86 platforms this will be rather hard to do
consistently. this really is a fundamental ARM issue.
On Alpha there have been similar troubles.
>
> > 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.
> >
>
> Right. The problem still happens when you lose packedness information, like
>
> struct packed_s
> {
> char a;
> int b;
> } __attribute__((packed));
>
>
> struct packed_s* p;
>
> int* pp = (int*)p->b;
>
> Here pp is a pointer to an int, and knows nothing about the fact that
> p->b may be unaligned.
the above code is perfectly valid for x86.. For compatibility a handler
could help out here. Just to keep the code from breaking.
Best practice however dictates that the above is not the right way to do
these things especially when looking at cross platform compatibility.
Unfortunately 90% of al programmers have not programmed on a platform
different from the x86.. (i have had the privillege to program on sparc,
PA-risc, Alpha, x86, 68000, and ARM. Each has its own peculiarities..)
in the world of open source these alignment problems have been fixed
only in the kernel of Linux and a few projects.. keeping in the line of
best-practices has been in favour of the ARM platforms lately but this
is in my experience only in the last few years..
>
>
> > 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.
> >
>
> Right on track.
>
> > 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.
> >
>
> That why I written "bug", not bug.
I understand. the sad thing is that gcc can keep people from doing
things in a platform dependant way..
from the back of my mind, I read somewhere:
"C gives you enough rope to hang yourself with."
>
>
> > 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..
> >
>
> Right. The handler catches more than alignment faults. It maps windows
> exceptions to unix signals. SIGSEGV happens to be the one I remembered
> trying :)
The handler should specifically check if the alignment fault bit is set.
it might mistake a data-abort for a segmentation fault..
>
>
> > Not sure what was meant here but proper SEGV signals etc. would be very
> > nice to have.
> >
>
> What do you mean by proper? You should be able to have a signal handler
> being called on an SEGV, but don't expect core dump support :)
>
A long time ago I had written some virtual memory methods and
single-step methods for ARM under linux. Those bits can only work if a
signal handler can be installed with the full sigset and so on.
I may have overlooked the recent development with cegcc but I had not
been able to use such methods with cegcc yet.
>
> >>
> >>> 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..)
>
> Right, unless Danny was building for FPA, with fpu abi = hard,
> in that case, if the division op is emitted, he should get a SIGILL.
which would mean that Windows CE does not have a Floating-point
emulator..
That is something I did not know.
>
> >>
> >> (Any brave soul to implement proper ARM WinCE SEH
> >> support on gcc ?)
> >
> > Forgive my lack of knowledge her but what is SEH?
>
> Structured Exception Handling. __try/__catch/__finally that
> also works on C. gcc must be the only compiler for windows that doesn't
> support it. The OS implements half of it. Google is your friend. :)
Structured exception handling is not part of C but of C++. Unfortunately
Microsoft has the habit of reinventing standards and have implemented
this in their C compilers.. try the DCE exception handling and you will
discover that it is exactly that which I missed in the signal handling.
By using setjmp etc. these things can be nicely implemented.
guess we cannot change how WinCE behaves, only work within its
parameters.
>
> 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
