| Ticket Hash: | c3fad42cdeea34e8fd3c984b8e2c3e2f9e594829 | ||
| Title: | Multiple warnings from patch command while building images | ||
| Status: | Closed | Type: | Build Problem |
| Severity: | Important | Priority: | Immediate |
| Subsystem: | os8-run | Resolution: | Fixed |
| Last Modified: |
2020-12-09 06:21:53 5.05 years ago |
Created: |
2020-07-10 15:07:09 5.46 years ago |
| Version Found In: | 1f1ac14196a8cf81618ce422f204b90c5d747bdc | ||
| User Comments: | ||||
jcwren added on 2020-07-10 15:07:09:
Not sure how important these are or not, since they didn't affect the v3d.rk05 image that I'm mostly concerned with. Search for 'Aborting patch'. There are 6 instances of it. tangent added on 2020-07-10 17:47:27:
This looks like one for Dr. Cattey... poetnerd added on 2020-07-12 03:08:36:
Yup. This one is mine to debug. I understand why 5 of them happen. The build being run has disabled install of fortran-iv, and five of those aborts are for fortran-iv. The script is supposed to be ignoring the fortran-iv patches when fortran-iv is disabled. But I see that I've been matching on fortran_iv, not fortran-iv. Commit 70b6053e6d fixes this typo. Would you please re-run your test? I would classify this as a partial fix. It is a mystery to me why the ABSLDR patch is failing in How come you're disabling so much? jcwren added on 2020-07-14 21:03:12:
Looks like that fixes all except on warning, except when patching ABSLDR. Primarily because I don't need any of that stuff. Just looking to load the Life program and let it run when I'm not using it. Did that by forcing simh to save the state just after I hit the 'Z' key for the patterns, and then poetnerd added on 2020-07-16 02:45:18:
Thanks for re-testing. I'm glad to know that the partial fix was right. The root cause on the failed ABSLDR patch is going to be tricky. Notice how the old value found is different in the two runs. In the first failure it was 0006. In the second run it was 0075. This is a very valuable safety check to make sure we don't go overwriting random stuff when we know what we should find to replace. I've done some more digging into that patch. It turns out that the purpose of the patch is to disable code that was supposed to adjust the Core Control Block when the KT8A memory extension option was present, giving the PDP-8 more than 32K of memory. But apparently that code broke something else and needed to be disabled. So, in practice, the patch does not have much of any impact, since we never emulate the KT8A memory extension to go above 32K of memory. Still, patching with FUTIL is something that should work. This is the first use of the FUTIL patching code path, so there my be some subtle problem. I shall need to meditate on this. | ||||