From: Peter V. E. <pva...@de...> - 2005-08-19 16:43:33
Attachments:
ld-script.alpha-linux
|
Hello, I've been trying to build sbcl on alpha and found a few problems: - the ld-script does not work anymore. I've attached a new script I created, based on the constants in the old file. I've also seen that the linker _does_ know the -taso option, but the memory layout changes are not compatible. - there is a small typo in ./src/compiler/alpha/alloc.lisp in "define-vop (make-closure)" the "(:node-var node)" is not used. I commented it out. After this the resulting image crashes in cold load in posix-getcwd, on the extern-alien macro. Does anybody have a clue what could be wrong? pvaneynd@escher:~/sbcl/sbcl$ grep cwd src/runtime/sbcl.nm 0000000008063558 T ldso_stub__getcwd ... /unbinding the symbol ~A OS-COLD-INIT-OR-REINIT /entering linux-os.lisp OS-COLD-INIT-OR-REINIT /setting *DEFAULT-PATHNAME-DEFAULTS* /past make-trivial-default-pathname /entering INFINITE-ERROR-PROTECTOR, *CURRENT-ERROR-DEPTH*=.. 0x00000000 Argh! error in cold init, halting fatal error encountered in SBCL pid 1167: %primitive halt called; the party is over. LDB monitor ldb> backtrace Backtrace: <Frame 0x761d0040 [interrupted], CODE: 0x31109F27, INFINITE-ERROR-PROTECTOR, <no LRA>, PC: 0x130> <Frame 0x761d0020, CODE: 0x315BEE17, CONTROL-STACK-EXHAUSTED-ERROR, LRA: 0x315beecf, PC: 0x70> <Frame 0x761cffc0, CODE: 0x3118D3BF, ARRAY-DIMENSIONS, LRA: 0x3118d497, PC: 0xb8> <Frame 0x761cff40, CODE: 0x31A13567, %%TYPEP, (Not other pointer???), LRA: 0x31a13ccf, PC: 0x630> <Frame 0x761cff00, CODE: 0x3125F887, COERCE, LRA: 0x3125fa6f, PC: 0xb8> <Frame 0x761cfea0, CODE: 0x31ACA857, EXTERN-ALIEN-NAME, (Not other pointer???), LRA: 0x31aca9ef, PC: 0x168> <Frame 0x761cfe80, CODE: 0x31ACB4D7, FIND-FOREIGN-SYMBOL-IN-TABLE, LRA: 0x31acb5df, PC: 0xd0> <Frame 0x761cfe60, CODE: 0x31ACC107, FOREIGN-SYMBOL-ADDRESS, LRA: 0x31acc26f, PC: 0x138> <Frame 0x761cfe40, CODE: 0x31ACCA47, FOREIGN-SYMBOL-SAP, LRA: 0x31accb97, PC: 0x128> <Frame 0x761cfe20, CODE: 0x31AC07D7, DLERROR, LRA: 0x31ac085f, PC: 0x58> <Frame 0x761cfe00, CODE: 0x31AC8647, FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, LRA: 0x31ac86e7, PC: 0x68> <Frame 0x761cfde0, CODE: 0x31AC979F, LIST-DYNAMIC-FOREIGN-SYMBOLS, DYNAMIC-FOREIGN-SYMBOLS-P, UNDEFINED-FOREIGN-SYMBOLS-P, ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, (Not other pointer???), LRA: 0x31ac9b77, PC: 0x360> <Frame 0x761cfdc0, CODE: 0x31ACC107, FOREIGN-SYMBOL-ADDRESS, LRA: 0x31acc2df, PC: 0x1a8> <Frame 0x761cfda0, CODE: 0x31ACCA47, FOREIGN-SYMBOL-SAP, LRA: 0x31accb97, PC: 0x128> <Frame 0x761cfd80, CODE: 0x31AC07D7, DLERROR, LRA: 0x31ac085f, PC: 0x58> <Frame 0x761cfd60, CODE: 0x31AC8647, FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, LRA: 0x31ac86e7, PC: 0x68> <Frame 0x761cfd40, CODE: 0x31AC979F, LIST-DYNAMIC-FOREIGN-SYMBOLS, DYNAMIC-FOREIGN-SYMBOLS-P, UNDEFINED-FOREIGN-SYMBOLS-P, ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, (Not other pointer???), LRA: 0x31ac9b77, PC: 0x360> <Frame 0x761cfd20, CODE: 0x31ACC107, FOREIGN-SYMBOL-ADDRESS, LRA: 0x31acc2df, PC: 0x1a8> <Frame 0x761cfd00, CODE: 0x31ACCA47, FOREIGN-SYMBOL-SAP, LRA: 0x31accb97, PC: 0x128> <Frame 0x761cfce0, CODE: 0x31AC07D7, DLERROR, LRA: 0x31ac085f, PC: 0x58> <Frame 0x761cfcc0, CODE: 0x31AC8647, FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, LRA: 0x31ac86e7, PC: 0x68> <Frame 0x761cfca0, CODE: 0x31AC979F, LIST-DYNAMIC-FOREIGN-SYMBOLS, DYNAMIC-FOREIGN-SYMBOLS-P, UNDEFINED-FOREIGN-SYMBOLS-P, ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, (Not other pointer???), LRA: 0x31ac9b77, PC: 0x360> <Frame 0x761cfc80, CODE: 0x31ACC107, FOREIGN-SYMBOL-ADDRESS, LRA: 0x31acc2df, PC: 0x1a8> <Frame 0x761cfc60, CODE: 0x31ACCA47, FOREIGN-SYMBOL-SAP, LRA: 0x31accb97, PC: 0x128> <Frame 0x761cfc40, CODE: 0x31AC07D7, DLERROR, LRA: 0x31ac085f, PC: 0x58> <Frame 0x761cfc20, CODE: 0x31AC8647, FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, LRA: 0x31ac86e7, PC: 0x68> <Frame 0x761cfc00, CODE: 0x31AC979F, LIST-DYNAMIC-FOREIGN-SYMBOLS, DYNAMIC-FOREIGN-SYMBOLS-P, UNDEFINED-FOREIGN-SYMBOLS-P, ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, (Not other pointer???), LRA: 0x31ac9b77, PC: 0x360> etc etc Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| |
From: Nikodemus S. <nik...@ra...> - 2005-08-19 17:10:55
|
On Fri, 19 Aug 2005, Peter Van Eynde wrote: > After this the resulting image crashes in cold load in posix-getcwd, on > the extern-alien macro. Does anybody have a clue what could be wrong? At a glance I'd suspect that one or more of the foreign symbol resolution functions isn't being transformed away, leading to infinite recursion. (See FOREIGN-SYMBOL-SAP / FOREIGN-SYMBOL-ADDRESS, and co). But then again, the machinery in question has been thru several revisions lately, so it could be anything really. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Christophe R. <cs...@ca...> - 2005-08-20 09:57:00
|
Peter Van Eynde <pva...@de...> writes: > Hello, > > I've been trying to build sbcl on alpha and found a few problems: > > - the ld-script does not work anymore. I've attached a new script I > created, based on the constants in the old file. I've also seen that the > linker _does_ know the -taso option, but the memory layout changes are > not compatible. OK. This is clearly an absolute pain, because the current CVS linker script works for me on a 2.2 kernel, while I believe Kevin's linker script for 2.4 was noticeably different. > - there is a small typo in ./src/compiler/alpha/alloc.lisp in > "define-vop (make-closure)" the "(:node-var node)" is not used. I > commented it out. Thanks for this; removing the node-var is right. > After this the resulting image crashes in cold load in posix-getcwd, on > the extern-alien macro. Does anybody have a clue what could be wrong? Not yet, but the "good" news is that the alpha build fails for me too (on the SourceForge Alpha) in what looks like the same way, so there's a decent chance that we can track it down. The last build that I made was 0.9.1.39, so sometime between then and now something changed for the worse. Since we're about to enter freeze and so opportunities for extravagant development are limited, I'll attempt to track it down before we release 0.9.4. Thanks, Christophe |
From: Christophe R. <cs...@ca...> - 2005-08-20 17:25:28
|
Peter Van Eynde <pva...@de...> writes: > I've been trying to build sbcl on alpha and found a few problems: > > - the ld-script does not work anymore. I've attached a new script I > created, based on the constants in the old file. I've also seen that the > linker _does_ know the -taso option, but the memory layout changes are > not compatible. Apart from this, I believe that sbcl-0.9.3.71, just checked in, has fixes for the build problems on alpha. As well as the unused (:node-var node) that you noted, the immediate cause of your crash was due to a missed renaming from foreign-symbol-address to foreign-symbol-sap; after fixing that, there was another problem from pointer alignment in structures, tickled by the introduction of thread objects. The version in CVS has just built and passed at least some tests on a Debian oldstable with a 2.2 kernel. Cheers, Christophe |
From: Peter V. E. <pva...@de...> - 2005-08-22 07:49:24
|
Christophe Rhodes schreef: > Apart from this, I believe that sbcl-0.9.3.71, just checked in, has > fixes for the build problems on alpha. As well as the unused > (:node-var node) that you noted, the immediate cause of your crash was > due to a missed renaming from foreign-symbol-address to > foreign-symbol-sap; after fixing that, there was another problem from Aha. Thanks for finding this. I guess you found it by looking at the code, or is there some magical trick? > pointer alignment in structures, tickled by the introduction of thread > objects. The version in CVS has just built and passed at least some > tests on a Debian oldstable with a 2.2 kernel. Without :sb-thread I guess? Thanks again for looking into this. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| |
From: Christophe R. <cs...@ca...> - 2005-08-22 08:18:38
|
Peter Van Eynde <pva...@de...> writes: > Christophe Rhodes schreef: >> Apart from this, I believe that sbcl-0.9.3.71, just checked in, has >> fixes for the build problems on alpha. As well as the unused >> (:node-var node) that you noted, the immediate cause of your crash was >> due to a missed renaming from foreign-symbol-address to >> foreign-symbol-sap; after fixing that, there was another problem from > > Aha. Thanks for finding this. I guess you found it by looking at the > code, or is there some magical trick? Thinking very hard usually helps. Actually I found it by looking at the Changelog from "cvs2cl version.lisp-expr" (see, there's a _reason_ we ask people to increment that on every commit :-) and examining the logs for changes in foreign symbol resolution; I found the 0.9.2.26 commit quite easily (by searching for "foreign"), and then it was just a matter of looking at that diff and seeing what was missing. >> pointer alignment in structures, tickled by the introduction of thread >> objects. The version in CVS has just built and passed at least some >> tests on a Debian oldstable with a 2.2 kernel. > > Without :sb-thread I guess? On the alpha? Yes :-) but thread objects exist even in the single-threaded world, because the initial thread is one. > Thanks again for looking into this. Thank you for the report! (Ah, it will be nice to have this automated...) Cheers, Christophe |