Danny Backx wrote:
> First to clear something up : my toolchain build problem is solved, you
> may have missed that in the many messages on the list these days.
> Apparently some of the newlib files get compiled wrong with the default
> build options (-O2 -O).
>
> On Sat, 2007-04-21 at 04:11 +0200, Jan Rinze wrote:
>
>>> 2. Pedro asked why I used a dialog, wouldn't a printf statement be
>>> better, he mentioned console applications.
>>> I've tried to build a "console" version of my follow-a-null-pointer
>>> application using the old voxware compiler. I used that toolchain
>>> because I don't think ours can handle a console application that
>>> can be launched from the rlogin session.
>>>
>> hmm.. that would be an issue by itself. I have run different tests in a
>> console on various things with cegcc but always used telnet for that.
>> don know about rlogin on the pocket pc.
>>
>
> Out of curiosity - which telnet server do you use?
>
>
>>> The console application died as expected, showing messages that appear
>>> to come from the _eh_handler_ :
>>>
>>> # np.exe
>>> Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:11054 R0:0
>>> R1:29150 R2:2 R3:0 R4:2009fb64 R5:2009fc7c R12:1 FP:2009fb4c
>>> Exception: Code:c0000005 Flags:0 Addr:11060 SP:2009fb44 LR:16194
>>> R0:ffffffff R1:0 R2:24be49ba R3:0 R4:c0000005 R5:0 R12:1 FP:2009fb4c
>>> Exception: Code:80000002 Flags:0 Addr:16198 SP:2009fb44 LR:16194
>>> R0:ffffffff R1:0 R2:24be49ba R3:86 R4:c0000005 R5:ffffffff R12:1
>>> FP:2009fb4c
>>> #
>>>
>> why 3 exceptions? should not one be enough and stop the program ( or am
>> I missing the correct mindset here to understand what is going on?)
>>
>
> Haven't looked into this one yet.
>
>
>>> Interestingly, the divide-by-zero application (which pops up a dialog
>>> after the division by 0) shows a dialog on my PDA's screen, even
>>> though it was launched as a console application (from the rlogin
>>> session).
>>>
>>>
>> could be from the floatingpoint emulator (if that exists on wince)
>>
>
> Again I should have been more clear. The app is
> #include <stdio.h>
> #include <stdlib.h>
>
> main()
> {
> double a, b;
>
> b = 0.0;
> a = 1.0 / b;
>
> MessageBoxW(0, L"All done", L"main", 0);
> return;
> }
>
> and it doesn't crash on the division, it does show the "All done" dialog
> even when it was run from an rlogin session. The point is that the
> dialog shows up at all.
>
>
Try this instead:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
float zero = 0.0;
float c = 5.3f / zero;
printf ("c = %f\n", c);
MessageBoxW(0, L"All done", L"main", 0);
return 0;
}
And build with:
arm-wince-mingw32ce-gcc main.c -o main.exe -mfpu=fpa -mfloat-abi=hard -O0
I see an fdvs insn emitted. I know close to nothing on FPA, but
that seems like a division op. Have no idea if the co-processor
traps that division. Anyway, this seems all pretty much moot, since
FPA is deprecated. If you want to optimize floating point, you should
check if your processor has VFP or something else.
> Once more, I tried to express too much with a limited amount of
> words :-)
>
> It is an application I built myself, a port of Xinvest
> (http://xinvest.sunsite.dk) which I call PocketInvest. The sources are
> in the same CVS as Xinvest, they overlap quite a bit.
>
> There's a report window, in which you can ask for analysis of your stock
> evolution over several periods. It is possible to have several periods
> (a month, last quarter, a year, ..) selected at the same time, the
> report gets bigger (more information is created).
>
> With one or two report periods, the app works. When I select five ("too
> much"), the application mysteriously dies.
>
> I have no idea why, the only thing I know is what gdb say (see below)
> but I can't map the address into a known location in the source.
>
> This mysterious crash is one of the reasons why I started looking into
> exception trapping.
>
> Any clues ?
>
>
>
>>> When I run it under gdb, all that happens is :
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x01758f58 in ?? ()
>>> (gdb) where
>>> #0 0x01758f58 in ?? ()
>>> (gdb)
>>>
>>>
>> sounds like a trashed stack. This can happen when you define arrays
>> within a function (created on the stack) and write outside the array
>> bounds.
>>
>>
Could be that, since the gdb you are using maps both
EXCEPTION_ACCESS_VIOLATION and STATUS_STACK_OVERFLOW
to SIGSEGV.
Or you are requesting too much resources (eg: memory/malloc) , and
not checking for failure, and then dereference an invalid resource
(HANDLE, void*, whatever)?
If the app crashes always at that address, you could try to single step into
the problem instead of waiting for the process to crash to get a stack
trace. Put a breakpoint somewhere where you know the app passes
and step from there until the crash. Perhaps you've already done that :)
If the app crashes in different places all the time, using printf
debugging, and, you'll have to start disabling parts of the app until
you know what component is causing the trouble. Eg: disable the
report painting, then the report calculation, etc., you should
know what to disable :)
Just out of curiosity, if this is a GUI app, why make it depend on
cegcc.dll? Why not port it to mingw32ce?
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
