pa reload problem
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 28 lines · Richard Hirst
Hi Alan,
I think I've found a case where it calls an external function with
dp corrupt,sym53c8xx.cagain, inncr_setsync(). Don't know if this is relevant given what you now know about the bug..L2977:
ldh 66(%r3),%r28 extrw,u %r28,31,16,%r19 extrw,u %r19,30,31,%r26 copy %r19,%r25 add,l %r21,%r26,%r26 .IMPORT $$divU,MILLICODE b,l $$divU,%r2 << stub will corrupt dp ldi 2000,%r20 cmpb,<< %r20,%r19,.L2978 extrd,u %r29,63,32,%r5 ldh 1688(%r6),%r20 ldi 32,%r19 cmpb,= %r19,%r20,.L2978 ldi 33,%r19 cmpb,=,n %r19,%r20,.L2978 ldd 1632(%r6),%r26 ldo -16(%r30),%r29 b,l _gsc_readb,%r2 << enters stub with wrong dp ldo 78(%r26),%r26 copy %r4,%r27 ldd 1632(%r6),%r25
Quoted 1 line
I hope I'm not supposed to do anything special with that $$divU call,
Unfortunately, I think you are supposed to. All the $$ routines are from the millicode library, and are treated specially by the linker. When doing a final link, these functions are never supplied by a shared library, but must come from a static lib like libgcc.a, or libmilli.a. This has the effect of never calling these routines via the .plt, and so dp is preserved. gcc isn't doing anything wrong here.
If you use a long branch stub that only trashes r1, you should be OK. _Don't load dp for these routines! (I hope all libmilli routines are re-entrant - if not, we'd probably have weird kernel crashes...)
Note that all of the above applies to 32-bit modutils too.
Alan
Signature · 1 line
Linuxcare. Support for the Revolution.
Quoted 9 lines · Alan Modra
Quoted 1 line
I hope I'm not supposed to do anything special with that $$divU call,
Unfortunately, I think you are supposed to. All the $$ routines are from the millicode library, and are treated specially by the linker. When doing a final link, these functions are never supplied by a shared library, but must come from a static lib like libgcc.a, or libmilli.a. This has the effect of never calling these routines via the .plt, and so dp is preserved. gcc isn't doing anything wrong here.
Quoted 3 lines
If you use a long branch stub that only trashes r1, you should be OK. _Don't load dp for these routines! (I hope all libmilli routines are re-entrant - if not, we'd probably have weird kernel crashes...)
OK, done that, thanks.
Quoted 1 line
Note that all of the above applies to 32-bit modutils too.
Shouldn't be an issue with 32 bit, as kernel and modules all have the same dp there.
Richard
Quoted 4 lines · Richard Hirst
Quoted 1 line
Note that all of the above applies to 32-bit modutils too.
Shouldn't be an issue with 32 bit, as kernel and modules all have the same dp there.
Yes, silly me. 32 bit is non-pic, so you don't need to worry about it. (%r19 in 32 bit case)
Signature · 1 line
Linuxcare. Support for the Revolution.
Quoted 9 lines · Richard Hirst
Quoted 5 lines
Quoted 2 lines
Note that all of the above applies to 32-bit modutils too.
Shouldn't be an issue with 32 bit, as kernel and modules all have the same dp there.
Yes, silly me. 32 bit is non-pic, so you don't need to worry about it. (%r19 in 32 bit case)
However, it may be an issue for 32 bit pic code under hpux. It is not clear to me why this didn't show up before with 32 bit pic code. For some reason, the circumstances which caused combine to delete the set restoring dp after function calls didn't seem to occur.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 7 lines · John David Anglin
Quoted 7 lines · Richard Hirst
Quoted 5 lines
Quoted 2 lines
Note that all of the above applies to 32-bit modutils too.
Shouldn't be an issue with 32 bit, as kernel and modules all have the same dp there.
Quoted 7 lines
Quoted 2 lines
Yes, silly me. 32 bit is non-pic, so you don't need to worry about it. (%r19 in 32 bit case)
However, it may be an issue for 32 bit pic code under hpux. It is not clear to me why this didn't show up before with 32 bit pic code. For some reason, the circumstances which caused combine to delete the set restoring dp after function calls didn't seem to occur.
Hi Dave,
Richard and I had wandered off-topic in the above exchange, and were
talking about modutils and stubs, in particular stub calls to millicode.
Getting back on topic, the reload problem _does_ affect 32 bit hppa code. Compiling my testcase with -O2 -fPIC -S, gives
copy %r19,%r4
bl foo,%r2
stw %r19,-32(%r30)
addil LT'cpu_hz,%r4
copy %r1,%r21
addil LT'.LC0,%r19 ! oops
ldw RT'cpu_hz(%r21),%r21
ldw RT'.LC0(%r1),%r1Alan
Signature · 1 line
Linuxcare. Support for the Revolution.
Quoted 7 lines
Hi Dave,
Richard and I had wandered off-topic in the above exchange, and were
talking about modutils and stubs, in particular stub calls to millicode.Getting back on topic, the reload problem _does_ affect 32 bit hppa code. Compiling my testcase with -O2 -fPIC -S, gives
Quoted 6 lines
copy %r19,%r4
bl foo,%r2
stw %r19,-32(%r30)
addil LT'cpu_hz,%r4
copy %r1,%r21
addil LT'.LC0,%r19 ! oopsFor some reason, I only saw this with the 64 bit version.
There is one other bit of code in rtlanal.c related to the patch which bothers me. I am wondering if it is ok or needs changing:
#ifndef PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
/* ??? When call-clobbered, the value is stable modulo the restore
that must happen after a call. This currently screws up local-alloc
into believing that the restore is not needed. */
if (x == pic_offset_table_rtx)
return 0;#endif
This is in rtx_unstable_p and rtx_varies_p. Possibly, now that there is a use until reload is complete, this problem is fixed and the pic_offset_table_rtx should be stable even when PIC_OFFSET_TABLE_REG_CALL_CLOBBERED? See comment at beginning of rtx_varies_p.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 11 lines · John David Anglin
Quoted 9 lines
Getting back on topic, the reload problem _does_ affect 32 bit hppa code. Compiling my testcase with -O2 -fPIC -S, gives
copy %r19,%r4 bl foo,%r2 stw %r19,-32(%r30) addil LT'cpu_hz,%r4 copy %r1,%r21 addil LT'.LC0,%r19 ! oopsFor some reason, I only saw this with the 64 bit version.
Probably because it only appears with -fpic (or -fPIC), which you get for free on pa64
Quoted 9 lines
There is one other bit of code in
rtlanal.crelated to the patch which bothers me. I am wondering if it is ok or needs changing:#ifndef PIC_OFFSET_TABLE_REG_CALL_CLOBBERED /* ??? When call-clobbered, the value is stable modulo the restore that must happen after a call. This currently screws up local-alloc into believing that the restore is not needed. */ if (x == pic_offset_table_rtx) return 0;
Quoted 7 lines
#endif
This is in
rtx_unstable_pandrtx_varies_p. Possibly, now that there is a use until reload is complete, this problem is fixed and thepic_offset_table_rtxshould be stable even whenPIC_OFFSET_TABLE_REG_CALL_CLOBBERED? See comment at beginning ofrtx_varies_p.
Likely so. With rth's latest patch to calculate_global_regs_live, it's possibile that I can remove some of the ARG_POINTER_INVARIANT patch too.
Signature · 1 line
Linuxcare. Support for the Revolution.