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.
> 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.
> 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.
> 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 :)
> 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 :)
>>
>>> 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.
>>
>> (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. :)
Cheers,
Pedro Alves
-------------------------------------------------------------------------
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
