GCL and GC on hppa
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 camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: