Greetings! Some time ago, you graciously contributed the following register flushing code to GCL:
============================================================================= #if defined(__hppa__) /* Courtesy of Lamont Jones */ /* the calling sequence */ struct regs { void *callee_saves[16]; }; void hppa_save_regs(struct regs); /* the code */ asm(".code"); asm(".export hppa_save_regs, entry"); asm(".proc"); asm(".callinfo"); asm(".label hppa_save_regs"); asm(".entry"); asm("stw %r3,0(%arg0)"); asm("stw %r4,4(%arg0)"); asm("stw %r5,8(%arg0)"); asm("stw %r6,12(%arg0)"); asm("stw %r7,16(%arg0)"); asm("stw %r8,20(%arg0)"); asm("stw %r9,24(%arg0)"); asm("stw %r10,28(%arg0)"); asm("stw %r11,32(%arg0)"); asm("stw %r12,36(%arg0)"); asm("stw %r13,40(%arg0)"); asm("stw %r14,44(%arg0)"); asm("stw %r15,48(%arg0)"); asm("stw %r16,52(%arg0)"); asm("stw %r17,56(%arg0)"); asm("bv 0(%rp)"); asm("stw %r18,60(%arg0)"); asm(".exit"); asm(".procend"); asm(".end"); #endif ============================================================================= I notice in gdb on paer that there are actually quite a few more regs which look like they might contain data pointers: ============================================================================= (gdb) i reg flags 0x0 0 r1 0x286494 2647188 rp 0xa9377 693111 r3 0x2 2 r4 0xc02a1f70 3223986032 r5 0x493c94 4799636 r6 0x286ca8 2649256 r7 0x4b3c94 4930708 r8 0x32cc94 3329172 r9 0x61aad4 6400724 r10 0x0 0 r11 0x4b3fa8 4931496 r12 0x0 0 r13 0x0 0 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x4dc9d8 5097944 r20 0x28 40 r21 0x0 0 r22 0x32c748 3327816 ---Type <return> to continue, or q <return> to quit--- r23 0x0 0 r24 0x278d5e 2592094 r25 0x2 2 r26 0xc02a1f0c 3223985932 dp 0x26bc94 2538644 ret0 0x239800 2332672 ret1 0x0 0 sp 0xc02a2100 3223986432 r31 0xa91e3 692707 sar 0x1c 28 pcoqh 0xa9377 693111 pcsqh 0x0 0 pcoqt 0xa937b 693115 pcsqt 0x0 0 eiem 0x0 0 iir 0x0 0 isr 0x0 0 ior 0x0 0 ipsw 0x4000b 262155 goto 0x0 0 sr4 0x0 0 sr0 0x0 0 sr1 0x0 0 ============================================================================= I know you've already responded that nothing recent should have changed this, but I am getting definite GC failure at modest gcc optimization levels which used to work on hppa, and am wondering perhaps if more recent compilers are using more registers. Separately, it appears that hppa has joined ia64 now in its handling of function descriptors, i.e. there being some sort of trampoline in a dynamically loaded shared memory area. Thankfully we have a work around for ia64 which appears to work here too (GCL needs to be able to dump unchanging function addresses into an executable file image). I bring this up because ia64 is the only other arch with special gc support in GCL: #if defined(__ia64__) asm(" .text"); asm(" .psr abi64"); asm(" .psr lsb"); asm(" .lsb"); asm(""); asm(" .text"); asm(" .align 16"); asm(" .global GC_save_regs_in_stack"); asm(" .proc GC_save_regs_in_stack"); asm("GC_save_regs_in_stack:"); asm(" .body"); asm(" flushrs"); asm(" ;;"); asm(" mov r8=ar.bsp"); asm(" br.ret.sptk.few rp"); asm(" .endp GC_save_regs_in_stack"); void * GC_save_regs_in_stack(); #endif There are two stacks which need saving on ia64. Could something similar have been added to hppa too? Take care, and thanks again! Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]