In article <[EMAIL PROTECTED]>, John Gruenenfelder wrote:
> I have a fairly large m68k project (Weasel Reader) that I've built with
> prc-tools 2.3.
>
> Recently, I've been rewriting some of the graphics code in a class framework
> to make my life simpler. Unfortunately, it seems that when one of my objects'
> destructors is called, the device jumps off someplace random on return from
> the destructor.
>
> For example, I have a pure virtual base class:
>
> class Widget {
> public:
> virtual ~Widget(void) { }
> virtual Boolean foo(void) = 0;
> };
>
> And an inherited class that does the work:
>
> class Bar : public Widget {
> Bar(void);
> ~Bar(void);
> Boolean foo(void);
> };
>
> Bar::~Bar(void)
> {
> // Nothing to do, just return
> }
>
>
> In my code, I create Bar via new, enter my event loop, then do some
> processing. When the user returns to the index form, the object is destroyed
> via delete. The destructor is run and all seems fine. When the destructor
> returns, it does *not* return to where it should.
>
> I should mention that the Bar class is in another code segment. If I place it
> in the default segment, my code works just fine. Of course, the default
> segment is just too small to hold these objects. I should also mention that
> the code calling Bar's destructor is itself in a different segment.
>
> What is going on? This is the first time I've used any C++ class stuff with
> prc-tools... are there any caveats I should be aware of? Specifically with
> multi-segment programs?
>
> This is with prc-tools 2.3 which I compiled myself in mid-January.
>
> One more note: When I say that the return jump from the destructor doesn't go
> to the correct place, I base that upon what I see in the debugger. GDB
> doesn't handle multiple segments well, but I have applied the Msect GDB
> patch... but I suppose it's possible that what I see in the debugger may not
> actually be correct.
>
> I'm confused...
>
>
I am afraid I cannot give much direct help, but only a few caveats:
- I have never tested my multisection debugging patches on 'real' C++
code, so there might be additional fixes needed for C++.
- Also, as you know, m68k-palmos-gcc is based on gcc-2.95.3 which predates
the C++ standard, so also there might be problems.
When I have some time (not very likely ;-)) I'll take a look at the weasel
reader code on sourceforge and see if there are any problems there with
running it through gdb.
By the way, is the code working without gdb, or crashing when returning
from the destructor?
Ton van Overbeek
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
