Hi,
A small reproducer is attached, gives on our x86 target:
throw
terminate called after throwing an instance of 'Except'
Johnny
> Are there any known problems with C++ exceptions?
>
> We have a test that throws a C++ exception which we catch higher up in
> the
> call chain. We now see with CE
Hi,
> A small reproducer is attached, gives on our x86 target:
> throw
> terminate called after throwing an instance of 'Except'
The static method is not needed, just a throw from a C++ exception causes
the abort? Maybe some configuration setting is lacking. Can someone try the
same program with
I've added a line in the catch phrase to assess whether it gets there.
On ARM, the program doesn't cause the usual CE Error report, so I guess
it doesn't really crash.
It never makes it into the catch part though - that statement never gets
executed. I tried both with a printf statement like you
Hi,
> I've added a line in the catch phrase to assess whether it gets there.
>
> On ARM, the program doesn't cause the usual CE Error report, so I guess
> it doesn't really crash.
Does it print the next line?
terminate called after throwing an instance of 'Except'
> It never makes it into the c
And when single-stepping this with gdb, the application terminates
(logging see below) when executing the throw.
Danny
pavilion: {10} rsh ipaq /temp/gdbserver : /temp/excepttest
Process /temp/excepttest created; pid = -1007952498
Listening on port
Remote debugging from host 172.1
On Fri, 2009-05-15 at 11:02 +0200, Johnny Willemsen wrote:
> > I've added a line in the catch phrase to assess whether it gets there.
> >
> > On ARM, the program doesn't cause the usual CE Error report, so I guess
> > it doesn't really crash.
>
> Does it print the next line?
> terminate called af
On Fri, 2009-05-15 at 11:02 +0200, Johnny Willemsen wrote:
> This looks a real major issue, if try/catch doesn't work then a lot of C++
> programs (including TAO) don't work.
It looks like we end up in the default exception handler, see
src/gcc/libstdc++-v3/docs/html/18_support/howto.html
Its s
Hi,
> On Fri, 2009-05-15 at 11:02 +0200, Johnny Willemsen wrote:
> > This looks a real major issue, if try/catch doesn't work then a lot
> of C++
> > programs (including TAO) don't work.
>
> It looks like we end up in the default exception handler, see
> src/gcc/libstdc++-v3/docs/html/18_suppor
On Thu, 14 May 2009 20:44:40 +0200, "Johnny Willemsen"
wrote:
> Hi,
>
> I just found that structured exception handling (__try, __except,
> __finally)
> is not supported with cegcc. Are there plans/ideas to add this?
>
> Johnny
Hi,
about seh there are plans to add support for it and I had pro
> I always say it sucks to reply to myself but I keep doing it.
>
> These lines are from src/mingw/mingwex/pformat.c :
> #ifdef _WIN32
> /* TODO: make this unconditional in final release...
> * (see note at head of associated `#else' block.
> */
> #include "gdtoa.h"
>
> static
> char *__pformat_
Hi,
> > This looks a real major issue, if try/catch doesn't work then a lot
> of C++
> > programs (including TAO) don't work.
>
> It looks like we end up in the default exception handler, see
> src/gcc/libstdc++-v3/docs/html/18_support/howto.html
> Its source is in
> src/gcc/libstdc++-v3/libs
On Friday 15 May 2009 04:48:05, Danny Backx wrote:
> So you are using 3 platforms, where most of us are talking about 2 :
> - Linux = create a compiler that runs on MSYS
> - MSYS = use cegcc (create WinCE/ARM apps)
> - WinCE/ARM = use applications
>
> Right ?
>
> So what is preventing you from sk
On Friday 15 May 2009 01:24:54, Geoffroy Couprie wrote:
> Hello!
>
> Here is a small patch to allow cross-compiling of CeGCC. I run
> "build-mingw32ce.sh --host=i586-mingw32msvc" from Linux to build a CeGCC
> usable on Windows (I use it under MSYS).
Applied, thanks.
> gcc, g++, objdump, strings,
Hello,
After updating my toolchain to the latest svn revision, my application
won't work properly anymore, it seems to hang at some point. I narrowed
it down to the changes in the w32api directory. Prior to revision 1229,
it works correctly. (Between revision 1229 and 1241, it won't build.)
After
On Fri, 2009-05-15 at 15:31 +0200, Johnny Willemsen wrote:
> > > This looks a real major issue, if try/catch doesn't work then a lot
> > of C++
> > > programs (including TAO) don't work.
> >
> > It looks like we end up in the default exception handler, see
> > src/gcc/libstdc++-v3/docs/html/18_s
After a closer look at the commits... attached patch solves the problem:
Index: trunk/cegcc/src/w32api/include/kfuncs.h
===
--- trunk/cegcc/src/w32api/include/kfuncs.h (révision 1275)
+++ trunk/cegcc/src/w32api/include/kfuncs.h
Hmm. Oops :-(
Thanks for the fix.
Danny
On Fri, 2009-05-15 at 17:02 +0200, Pierre Ynard wrote:
> Index: trunk/cegcc/src/w32api/include/kfuncs.h
> ===
> --- trunk/cegcc/src/w32api/include/kfuncs.h (révision 1275)
> +++ tru
On Friday 15 May 2009 15:36:12, Geoffroy Couprie wrote:
> > Dunno. First, to be sure we're running the correct executables, use the
> > prefixed ones (arm-mingw32ce-ranlib|ar). What does arm-mingw32ce-objdump
> > -x say
> > on the object and on the archive?
> >
> >
> Yes, I'm using the prefi
Geoffroy Couprie a écrit :
> Pedro Alves a écrit :
>> On Friday 15 May 2009 01:24:54, Geoffroy Couprie wrote:
>>
>>> Hello!
>>>
>>> Here is a small patch to allow cross-compiling of CeGCC. I run
>>> "build-mingw32ce.sh --host=i586-mingw32msvc" from Linux to build a
>>> CeGCC
>>> usable on Window
Hi,
> > Would the gcc/mingw people have an idea where to search?
>
> It appears to be a DLL issue : when I compile with -static, the test
> program does work (on ARM).
>
> Johnnym, can you test on x86 ?
We will test this asap on our device. There are references of throwing
exceptions from dll's
On Sat, 2009-05-16 at 08:44 +0200, Johnny Willemsen wrote:
> > It appears to be a DLL issue : when I compile with -static, the test
> > program does work (on ARM).
> >
> > Johnnym, can you test on x86 ?
>
> We will test this asap on our device. There are references of throwing
> exceptions from d
Hi,
> I suspect that the warnings from LD are accurate in this case :
>
> This should work unless it involves constant data structures
> referencing symbols from auto-imported DLLs.
We do use enable-auto-import so far as I know. Will test a few things.
Johnny
-
22 matches
Mail list logo
