Pedro Alves escreveu:
> 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;
>
Obvously, I meant:
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
>
-------------------------------------------------------------------------
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
