Re: [PATCH, v2] Fix build on platforms where the stack grows upwards

[John David Anglin <dave.anglin@bell.net>]

On 2020-03-13 12:29 p.m., Andy Wingo wrote:
> On Tue 10 Mar 2020 23:58, John David Anglin <dave.anglin@bell.net> writes:
>
>> On 2020-02-08 9:07 a.m., Ludovic Courtès wrote:
>>> John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> skribis:
>>>
>>>>  * libguile/continuations.c (scm_dynthrow): Fix missing mra
>>>>    parameter to grow_stack for SCM_STACK_GROWS_UP.
>>> Applied, thanks!
>> I believe that this change was also applied to the 2.2 stable branch (v2.2.7).  There is no mra
>> parameter on 2.2.
> Indeed; fixed.  Thanks for the fix and the note, and thanks Ludo for
> getting the fix into 3.0.1 :)
guile-3.0 3.0.0+1-2 built successfully on debian linux:
https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=hppa&ver=3.0.0%2B1-2&stamp=1583969036&raw=0

On hpux, there are problems with the 2.2 and 3.0 branches.

2.0.14 builds okay on hppa2.0w-hp-hpux11.11 with gcc 8.4.1, but I had to upgrade intprops.h to a newer version.

Version 2.2.6 segfaults in vm_regular_engine:

     11378 Segmentation fault      (core dumped) | GUILE_AUTO_COMPILE=0 ../meta/build-env guild snarf-check-and-output-texi > guile-procedures.texi
make[3]: *** [Makefile:4281: guile-procedures.texi] Error 1

(gdb) bt
#0  vm_regular_engine (thread=0x7ad69e60, vp=0x7ad28f78, registers=0x7eff22d0,
    resume=0) at ../../libguile/vm-engine.c:573
#1  0xc2b540fc in scm_call_n (proc=0x7ad4fbc0, argv=0x0, nargs=0)
    at ../../libguile/vm.c:1260
#2  0xc29e5710 in scm_call_0 (proc=0x7ad4fbc0) at ../../libguile/eval.c:479
#3  0xc2a44e58 in scm_primitive_load_path (args=0x7ad50ff0)
    at ../../libguile/load.c:1251
#4  0xc2a1f0a0 in scm_apply_subr (sp=0x7acd7f30, nslots=2)
    at ../../libguile/gsubr.c:305
#5  0xc2b2f22c in vm_regular_engine (thread=0x7ad69e60, vp=0x7ad28f78,
    registers=0x7eff11d0, resume=0) at ../../libguile/vm-engine.c:786
#6  0xc2b540fc in scm_call_n (proc=0x7ad375c8, argv=0x0, nargs=0)
    at ../../libguile/vm.c:1260
#7  0xc29e5710 in scm_call_0 (proc=0x7ad375c8) at ../../libguile/eval.c:479
#8  0xc2a44e58 in scm_primitive_load_path (args=0x7ad38b20)
    at ../../libguile/load.c:1251
#9  0xc2a44f7c in scm_c_primitive_load_path (
    filename=0x7adce1ec <s_scm_nl_langinfo+676> "ice-9/boot-9")
    at ../../libguile/load.c:1267
#10 0xc2a31e8c in scm_load_startup_files () at ../../libguile/init.c:250
#11 0xc2a33864 in scm_i_init_guile (base=0x7eff0dd8)
    at ../../libguile/init.c:535
#12 0xc2b1ca80 in scm_i_init_thread_for_guile (base=0x7eff0dd8,
---Type <return> to continue, or q <return> to quit---
    dynamic_state=0x0) at ../../libguile/threads.c:586
#13 0xc2b1cdc0 in with_guile (base=0x7eff0dd8, data=0x7eff0d58)
    at ../../libguile/threads.c:654
#14 0xc11fc530 in GC_call_with_stack_base (fn=0x4, arg=0x7ad4fd08)
    at ../src/extra/../misc.c:2130
#15 0xc2b1d01c in scm_i_with_guile (
    func=@0x7adc477a: 0xc2a32000 <invoke_main_func>, data=0x7eff0c9c,
    dynamic_state=0x0) at ../../libguile/threads.c:704
#16 0xc2b1d0ac in scm_with_guile (
    func=@0x7adc477a: 0xc2a32000 <invoke_main_func>, data=0x7eff0c9c)
    at ../../libguile/threads.c:710
#17 0xc2a31fcc in scm_boot_guile (argc=6, argv=0x7eff0a84,
    main_func=@0x40001a7a: 0x3838 <inner_main>, closure=0x0)
    at ../../libguile/init.c:324
#18 0x00003b6c in main (argc=6, argv=0x7eff0a84) at ../../libguile/guile.c:101
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0xc2b2e99c to 0xc2b2e9bc:
   0xc2b2e99c <vm_regular_engine+1100>: addil L%-4800,r19,r1
   0xc2b2e9a0 <vm_regular_engine+1104>: copy r1,ret0
   0xc2b2e9a4 <vm_regular_engine+1108>: ldw e8(ret0),ret0
   0xc2b2e9a8 <vm_regular_engine+1112>: copy ret0,r6
=> 0xc2b2e9ac <vm_regular_engine+1116>: ldw 0(r6),r4
   0xc2b2e9b0 <vm_regular_engine+1120>: extrw,u r4,31,8,ret0
   0xc2b2e9b4 <vm_regular_engine+1124>: depw,z ret0,29,30,ret0
   0xc2b2e9b8 <vm_regular_engine+1128>: add,l r9,ret0,ret0
End of assembler dump.
(gdb) p/x $r6
$1 = 0xf4f25378
(gdb) p/x ip
$2 = 0xf4f25378
(gdb) x/x 0xf4f25378
0xf4f25378:     Cannot access memory at address 0xf4f25378

The above fault doesn't depend  on compiler optimization level.

I've tried to find the change that introduced the above using git bisect but it isn't easy.  There
are multiple places on the trunk where the build breaks.  In some places, stack overflows occur
due to excessive iteration.  Stack size is 16384 kbytes.

If you have any thoughts on the above, let me know.  Aside from the OS differences, the code generated
should be quite similar for both hpux and linux.

Dave

-- 
John David Anglin  dave.anglin@bell.net