[Gc] GC crash on OSX 10.3.1 (7C103)
Wed, 12 Nov 2003 21:48:51 -0800 (PST)
Is there an issue with signal frames? Generally unwinding correctly
through those is harder, but I think on X86 this style of unwinding
only results in some skipped frames, which would be OK.
In any case, it sounds like using this together with the OS facility
for thread enumeration would be a useful option ot have ...
On Wed, 12 Nov 2003, Andrew Begel wrote:
> On Nov 12, 2003, at 9:39 AM, Boehm, Hans wrote:
> > The existing code of course needs to deal with the case that it's not
> > initialized from the main thread. Depending on whether there are any
> > risks
> > involved in that version of the code (is the sort of stack unwinding
> > described
> > below always reliable, even with assembly frames on the stack?), it
> > may make
> > sense to only turn that on with the new option as well.
> According to the Apple Runtime architecture documentation for Mach-O
> programs, the PPC stack conventions are required to be followed by
> function callers and the SP isn't supposed to be moved by the callee
> until they're about to call another function. In addition, the stack
> frame is supposed to be a fixed size at compile time.
> The calling routine’s linkage area holds a number of values, some of
> which are saved by the calling routine and some by the called routine.
> The elements within the linkage area are as follows:
> • The Link Register (LR) value is saved at 8(SP) by the called
> routine if it chooses to do so.
> • The Condition Register (CR) value may be saved at 4(SP) by the
> called routine. As with the Link Register value, the called routine is
> not required to save this value.
> • The stack pointer is always saved by the calling routine as part of
> its stack frame.
> This layout is LR, followed by CR, followed by SP with the SP register
> (r1) moved to point at the saved SP in the stack frame.
> This all being said, an assembly program can do anything it wants until
> it calls out into other libraries' code, at which point it must follow
> these conventions (since the other libraries' entry points know that
> they can count on these rules when they are called).
> What isn't known is what SP the assembly code would put into the first
> stack frame it creates when calling out of its library. Apple's Libc
> seems to put NULL in the SP of the first stack frame, letting us detect
> the end of the stack. Any other non-gcc compiled language could put
> anything there and then use its own stack frame layout which would
> screw this code up. But hey, let the buyer beware. We can just put it
> in the docs. I know Apple's java follows this layout, and it's not
> Gc mailing list