Problems with condition handlers in MACRO32 on IA64

[Christopher Blackburn]

All,
I'm having problems with some MACRO32 code that has been ported to an IA64 platform from an ALPHA (orignally ported from a VAX). The software establishes a number of condition handlers that use the CHF$PH_MCH_FRAME offset into the MECHARGS to get the FP of the establishing routine such that memory allocated in the establisher can be freed up. When I debug the code the value of the FRAME offset within the MECHARGS looks like a valid address but does not seem to correspond with the SP address used within the establisher. Is there a simple way of deriving the SP of the establisher within a condition handler ?

Block of code within handler looks similar to this -

MOVQ 4(AP), R9
CMPL CHF$L_SIG_NAME(R9), #SS$_UNWIND
BNEQ 10$
MOVL CHF$PH_MCH_FRAME(R10), R11
SUBL2 #160, R11

PUSHL R11
CALL FREE_DATA

10$: RET

Code worked OK on the ALPHA but now seems to be pointing at the wrong stack space on the IA64. Are there any known problems accessing the MECHARGS on the IA64 platform ?

[John Gillings]

Christopher,

>Are there any known problems accessing
>the MECHARGS on the IA64 platform ?

In a sense, yes. It's a completely different calling standard.

IA64 doesn't use the VAX style FP chain. You can't just walk up the frame pointers and assume you've found the context of the caller like you could on VAX and Alpha (and even on Alpha it's sometimes invalid).

The "correct" way to do this kind of thing on both Alpha and IA64 is with the "Invocation Context" routines. LIB$GET_INVO_CONTEXT and (many!) friends.

On Alpha the OS could fake it out so the Alpha call frame looked enough like VAX to get away with it most of the time.

However, for IA64, the calling standard is so radically DIFFERENT that you need a completely new set of routines. Use LIB$GET_*INVO|UNWIND* for Alpha and LIB$IA64_* for IA64.

You'll need to read the docs. It's rather confusing to jump into, when you're used to the elegant simplicity of the VAX model, but once you get your head around the new concepts it makes sense.

[Christopher Blackburn]

John,
Thanks for your reply. I had a nasty feeling this was what was wrong but don't have enough experience of condition handlers and macro32 to know what to do.
I've been looking at the OpenVMS RTL book that describes the invokation context routines but it does not indicate how to declare an invovation context block.
It looks like I would need to create a context block and initialise its contents before calling the LIB$I64_GET_CURR_INVO_CONTEXT routine to get the invo context filled in.
All I actually need is the Stack Pointer value when the establisher was called such that items allocated on the stack can be cleaned up (i.e. files that have been opened and strings that have been allocated). It would appear from the Programming Concepts manual that the CHF$PH_MCH_FRAME offset within the MECHARGS provides the SP of the establisher but under the OpenVMS debugger the value in the PH_MCH_FRAME offset is sometimes a little adrift from the actual SP used by the establisher. This results in various crashed when strings etc. are freed as the stack references are some bytes out.
I will continue to look through the OpenVMS manuals and guides and see if I can piece it together.
Chris.

[Volker Halle]

Chris,

I don't think you can rely on 'temporary addresses' stored on the stack of the caller to enable the condition handler to clean up correctly. It might seem to work, but can start failing at any time when something is re-compiled.

It may be necessary to store adresses of data-structures 'more globally', if reliable access through a condition handler is desired.

Volker.

[Christopher Blackburn]

Volker,
Thanks for reply, I understand what you are saying but the code in question is just trying to close a file and free up dynamic string space for items that were allocated on the stack when the establisher was called. After the handler tidies up the stack is unwound by using $UNWIND to get back to the caller of the establisher. This mechanism worked OK on VAX and ALPHA but just seems to have a few problems on the IA64. Without a handler the signaled error will just cause execution to stop as it will be caught by the default handler and reported via a stack trace dump. The handler is trying to report the error via the SYS$PUTMSG service and then tidy up and carry on.

Chris.

[Hoff]

I'm with Volker here. Is it feasible to extricate the architecture dependencies?

It might be easier and more reliable and more maintainable to use a temporary VM zone or to wrap the VM calls and to then maintain a list of allocations. With a designated temporary VM zone, you can flush the whole thing in one call.

Or to you roll your own ("real") garbage collection, which is where this looks to be headed.

Stuff that directly wanders the classic VAX call stack is usually too clever by half, and both wicked difficult to port and potentially quite unstable.

I'd look to maintain a list or a queue of the events or tasks that need to be unwrapped or undone at each call-frame level, and have the exit handler at that level unwrap those events. Basically each allocation queues a deallocate, and each open queues a close, and the signal handler dequeues and fields each. For a more dynamic approach, you could queue functions or function pointers, and each dequeue in a generic signal handler then calls the associated function.

Or you own up to the issues, and implement full-on garbage collection. This means you usurp and wrap the the VM calls and the open calls and such, and you also figure out how to tell when the memory or the channel is active and referenced, and when it's not. For loop-local memory, you could use a loop counter or such, and periodically scan for blocks with old counters. For other memory allocations, use a reference counter. Reliable GC isn't an easy problem.

Even the non-Unix signal handling can be too non-portable for my tastes; when it's feasible within the constraints of the modifications, I prefer to leave the code more portable than when I started. If it's feasible here, use of signal(), handler() and raise() would be more portable.

[Christopher Blackburn]

Generally the condition handlers were working within the MACRO32 assembler when compiled on both the Alpha and Itanium platforms but on occassion the mec args were adrift. I have resolved the problem be re-writing that particular section of code.

Many thanks to those who replied.