This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: question about egcs
- To: Joe dot Golio at xylan dot com, egcs-bugs at egcs dot cygnus dot com
- Subject: Re: question about egcs
- From: mrs at wrs dot com (Mike Stump)
- Date: Fri, 4 Jun 1999 11:33:02 -0700
Just in case you don't know, Tornado 2.0 is out and it has support for
EH...
Other than that, you can put a breakpoint on __throw (or was it
___throw), and watch what happens. There is an rtti matcher, you can
put a breakpoint on it, and watch the types. In your case, they
should both be "i" as I recall.
Also, you might want to run the testsuite for g++ and see what you
get.
We are using sjlj-exceptions here (at wrs)... I noticed that in your
case, your using the nonsjlj expcetions. I haven't done much of
anything with that style here, so I can't say if it should work or
not. If you want an potentially easier path, you might want to turn
on sjlj expcetions instead.
Your problem may be that your regions are no being registered.
> Date: Fri, 04 Jun 1999 09:55:50 -0500
> From: "Joseph M. Golio" <Joe.Golio@xylan.com>
> To: egcs-bugs@egcs.cygnus.com
> I'm trying to get exceptions to work on a VxWorks sparclite machine using
> try/throw/catch. I'm having problems with a very
> simple test program.
> try {
> throw(100);
> }
> catch (int x) {
> printf("caught %d\n", x);
> }
> It compiles fine, but when I run it, I get the following:
> Exception: Memory Address Not Aligned
> program counter: 0x407ba5a8
> next program counter: 0x407ba5ac
> processor status register: 0x050010c3
> access address: 0x00000063
> 407c4ff0 _vxTaskEntry +c : _shell (1, 0, 0, 0, 0, 0)
> 407a9a50 _shell +fc : 407a9a7c (0, 3, 7f, 40a14800, 0, 0)
> 407a9c5c _shell +308: _execute (41dd88e8, 0, 80, 0, 41dd88e8, 41dd86d8)
> 407a9dc4 _execute +d4 : _yyparse (41dac248, 40a19400, ffffffff, 0,
> 41dd88f5, 41fd4cd8)
> 407a8b9c _yyparse +774: 407a6dd0 (41dac218, 41dac238, 10, 2bb, 4, 0)
> 407a6f2c _printSym +490: 41db9260 (0, 0, 0, 0, 0, 0)
> 41dc54b0 _cppTest__Fv +430: ___throw (41db9260, &___tii, 0, 41dd8670, 256,
> &_lexStateTable)
> 41dc601c ___throw +60 : ___terminate (0, 41dd82a8, 1, beef, 41dd8090,
> 41dd82a8)
> 41dc581c ___terminate +c : ___terminate (41dc9400, &___default_terminate,
> 4077bdc0, 1, 0, 1)
> 41dc5808 ___default_terminate+4 : _abort (0, ffffffff, 41dca000, 0, 2, 0)
> 4076935c _abort +4 : _raise (6, &_semMGive, &_semMTake, 10, fffffff8,
> 41dd86d8)
> 407aadb0 _raise +c : _kill (41dd8a60, 6, 2, 0, &_taskDeleteTable, 0)
> 407aaed0 _kill +110: 407ab638 (41dd8a60, 6, 6, 0, 0, 0)
> 407ab650 _sigPendDestroy+bc : 407ab1d0 (41dd8a60, 41dd7ba0, 0, 0, 0, 0)
> 407ab404 _kill +644: 407aaee8 (41dd7a70, 1, 41dd8a60, 409d2c00,
> 5401fc7, &_lexStateTable)
> 407aaf80 _kill +1c0: 407aa3cc (6, 0, 41dd7a70, beef, 41dd8090,
> 41dd82a8)
> 407a98e4 _shellRestart +bc : _trcStack (b, &_dbgPrintCall, 41dd8a60, 1, 0, 1)
> shell restarted.
> >From the stack trace, it appears as though my catch handler is not registered
> because of the call to
> terminate. I am linking with libgcc.
> Is there something very basic that I am doing wrong ?