Squeak5.3 linux ARMv6 segfaults on startup
Locked
1234
1234
Re: Squeak5.3 linux ARMv6 segfaults on startup
 
|
Hi, It looks like sudo apt-get install libgl1-mesa-dev replaces sudo apt-get install libgl-mesa-dev I'm guessing... cheers bruce 15 March 2020 20:55 tim Rowledge <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
> On 2020-03-15, at 1:11 PM, Bruce O'Neel <[hidden email]> wrote: > > > Hi, > > It looks like > > sudo apt-get install libgl1-mesa-dev > > replaces > > sudo apt-get install libgl-mesa-dev Looks like it; at least it built ok. Eventually we'll see if it works! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Oxymorons: Act naturally |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi, So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous for doing unaligned access with few complaints. Now this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html&_ga=2.65157998.1175841526.1584348406-1352071188.1515062694 claims that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in Debian/Raspberian, or the hardware, or ???? Of course, that might be a rabbit hole as well. cheers bruce /work/share/tmp/opensmalltalk-vm$ git bisect good f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e Author: smalltalking <[hidden email]> Date: Wed Jan 8 10:55:18 2020 +0000 Fix type inconsistencies (int vs sqInt) (#464) * Fix type inconsistencies (int vs sqInt) Found by trying to compile with LTO enabled. The VM compiles with the updated types on linux with or without LTO enabled (the LTO VM is not functional). Didn't test with the OSes but changed the declarations in their files. Affected functions: - primInIOProcessEventsFlagAddress - ioGatherEntropy - GetAttributeString - primitivePluginBrowserReady - primitivePluginDestroyRequest - primitivePluginRequestFileHandle - primitivePluginRequestState - primitivePluginRequestURL - primitivePluginRequestURLStream - primitivePluginPostURL * Include sqMemoryAccess.h to have sqInt defined :040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms :040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src Last good commit commit 0b4551db2e5c00f67502250d0336757ed12ab096 Merge: f219b7218 afbf9e015 Author: Fabio Niephaus <[hidden email]> Date: Mon Jan 6 17:08:45 2020 +0100 Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci skip] Fix image MC loading glitch in image build scripts when checking pack… With the last good commit I have a working ARM COG vm. Image ----- /work/share/tmp/Squeak5.3-19431-32bit.image Squeak5.3 latest update: #19431 Current Change Set: HomeProject Image format 6521 (32 bit) Virtual Machine --------------- /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 To Build A Similar Virtual Machine ---------------------------------- Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. Image ----- /work/share/tmp/Squeak6.0alpha-19511-32bit.image Squeak6.0alpha latest update: #19511 Current Change Set: HomeProject Image format 6521 (32 bit) Virtual Machine --------------- /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 To Build A Similar Virtual Machine ---------------------------------- Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. Tiny Benchmarks --------------- 320,000,000 bytecodes/sec; 19,000,000 sends/sec 15 March 2020 23:39 tim Rowledge <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
HI, If one wants to run this version you can download it from here. http://www.pckswarms.ch/arm/squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2 Do not that the normal rules apply about downloading and running random programs off the internet. % shasum -a 256 squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2 f3408bc075754a98b5656d7ccde3f3cad29d481940c4ec55ba80d721b0b940fa squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2 cheers bruce 16 March 2020 09:55 "Bruce O'Neel" <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hmm, the "bad" commit just replace int by sqInt which are equivalent on 32bits VM, I do not see what could go wrong on this side... It also include sqMemoryAccess.h, could it be that some macro in this file override an existing one? Is there any warning related in the LOG file? In such case, what we can do is to compiled -Wall and diff the warning LOG produced by the two versions (good and bad). Le lun. 16 mars 2020 à 10:35, Bruce O'Neel <[hidden email]> a écrit :
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by Bruce O'Neel-2
Hi Bruce,
(cc'd vm-dev list) That looks interesting. If you have a look at the output of git diff 0b4551db2e5c00f67502250d0336757ed12ab096 f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e you'll see that only the type declarations of a few methods changed, and the only change is that int was rewritten to sqInt. On 32-bit platforms sqInt is int, so that commit should make no difference at all. (just saw that Nicolas had a look at this as well) Are you sure that's the first bad commit? The next commit (0f0b5324b6e41cda7f92c335d45e563d41285ccd) contains multiple arm specific changes according to its message. E.g.: > Fix old bug in ARM32 LoadEffectiveAddressMwrR > Improve the ARM32 trampoline marshalling code fractionally. > A number of small improvements to context creation as part of reversing the > order of comparison of the SPReg with anythin g else, to suit ARMv8. > Get the ARMv5 "stop" instruction (BKPT) correct. Which version of gcc did you use to compile the VM? Levente On Mon, 16 Mar 2020, Bruce O'Neel wrote: > > Hi, > > So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous > for doing unaligned access with few complaints. > > Now this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html&_ga=2.65157998.1175841526.1584348406-1352071188.1515062694 claims that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in > Debian/Raspberian, or the hardware, or ???? > > Of course, that might be a rabbit hole as well. > > cheers > > bruce > > /work/share/tmp/opensmalltalk-vm$ git bisect good > > f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit > > commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e > > Author: smalltalking <[hidden email]> > > Date: Wed Jan 8 10:55:18 2020 +0000 > > > Fix type inconsistencies (int vs sqInt) (#464) > > > > * Fix type inconsistencies (int vs sqInt) > > > > Found by trying to compile with LTO enabled. > > The VM compiles with the updated types on linux with or without LTO enabled (the LTO VM is not functional). > > Didn't test with the OSes but changed the declarations in their files. > > Affected functions: > > - primInIOProcessEventsFlagAddress > > - ioGatherEntropy > > - GetAttributeString > > - primitivePluginBrowserReady > > - primitivePluginDestroyRequest > > - primitivePluginRequestFileHandle > > - primitivePluginRequestState > > - primitivePluginRequestURL > > - primitivePluginRequestURLStream > > - primitivePluginPostURL > > > > * Include sqMemoryAccess.h to have sqInt defined > > > :040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms > > :040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src > > > > > Last good commit > > > commit 0b4551db2e5c00f67502250d0336757ed12ab096 > > Merge: f219b7218 afbf9e015 > > Author: Fabio Niephaus <[hidden email]> > > Date: Mon Jan 6 17:08:45 2020 +0100 > > > Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci skip] > > > > Fix image MC loading glitch in image build scripts when checking pack… > > > > > > With the last good commit I have a working ARM COG vm. > > Image > ----- > /work/share/tmp/Squeak5.3-19431-32bit.image > Squeak5.3 > latest update: #19431 > Current Change Set: HomeProject > Image format 6521 (32 bit) > > Virtual Machine > --------------- > /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak > Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] > Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 > platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm > CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 > StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 > > To Build A Similar Virtual Machine > ---------------------------------- > Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the > "Clone or download" instructions, then read the top-level README.md > and HowToBuild files in the top-level build directory for your > platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. > > > Image > ----- > /work/share/tmp/Squeak6.0alpha-19511-32bit.image > Squeak6.0alpha > latest update: #19511 > Current Change Set: HomeProject > Image format 6521 (32 bit) > > Virtual Machine > --------------- > /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak > Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] > Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 > platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm > CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 > StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 > > To Build A Similar Virtual Machine > ---------------------------------- > Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the > "Clone or download" instructions, then read the top-level README.md > and HowToBuild files in the top-level build directory for your > platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. > > Tiny Benchmarks > --------------- > 320,000,000 bytecodes/sec; 19,000,000 sends/sec > > > 15 March 2020 23:39 tim Rowledge <[hidden email]> wrote: > > > > On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote: > > > > > > Hi, > > > > It looks like > > > > sudo apt-get install libgl1-mesa-dev > > > > replaces > > > > sudo apt-get install libgl-mesa-dev > > Looks like it; at least it built ok. Eventually we'll see if it works! > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Oxymorons: Act naturally > > > > > > > |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
(cc'd vm-dev for real)
On Mon, 16 Mar 2020, Levente Uzonyi wrote: > Hi Bruce, > > (cc'd vm-dev list) > That looks interesting. > If you have a look at the output of > > git diff 0b4551db2e5c00f67502250d0336757ed12ab096 > f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e > > you'll see that only the type declarations of a few methods changed, and the > only change is that int was rewritten to sqInt. > On 32-bit platforms sqInt is int, so that commit should make no difference at > all. > (just saw that Nicolas had a look at this as well) > > Are you sure that's the first bad commit? > > The next commit (0f0b5324b6e41cda7f92c335d45e563d41285ccd) contains multiple > arm specific changes according to its message. E.g.: > >> Fix old bug in ARM32 LoadEffectiveAddressMwrR >> Improve the ARM32 trampoline marshalling code fractionally. > >> A number of small improvements to context creation as part of > reversing the >> order of comparison of the SPReg with anythin g else, to suit ARMv8. > >> Get the ARMv5 "stop" instruction (BKPT) correct. > > Which version of gcc did you use to compile the VM? > > > Levente > > On Mon, 16 Mar 2020, Bruce O'Neel wrote: > >> >> Hi, >> >> So since I can seem to build things on my PI, I spent last evening running >> git bisects. What that came up with was below. The first bad commit does >> seem like somewhere things could go bad with 32 vs 64 bit, and, possibly >> unaligned access? Our main test case are the x86 and the x86-64 machines >> which are famous >> for doing unaligned access with few complaints. >> >> Now >> this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html&_ga=2.65157998.1175841526.1584348406-1352071188.1515062694 claims >> that as of ARMv6 unaligned access is allowed and done in hardware. One >> wonders if it is completely correctly done, and, this isn't something in >> Debian/Raspberian, or the hardware, or ???? >> >> Of course, that might be a rabbit hole as well. >> >> cheers >> >> bruce >> >> /work/share/tmp/opensmalltalk-vm$ git bisect good >> >> f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit >> >> commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e >> >> Author: smalltalking <[hidden email]> >> >> Date: Wed Jan 8 10:55:18 2020 +0000 >> >> >> Fix type inconsistencies (int vs sqInt) (#464) >> >> >> >> * Fix type inconsistencies (int vs sqInt) >> >> >> >> Found by trying to compile with LTO enabled. >> >> The VM compiles with the updated types on linux with or without LTO >> enabled (the LTO VM is not functional). >> >> Didn't test with the OSes but changed the declarations in their files. >> >> Affected functions: >> >> - primInIOProcessEventsFlagAddress >> >> - ioGatherEntropy >> >> - GetAttributeString >> >> - primitivePluginBrowserReady >> >> - primitivePluginDestroyRequest >> >> - primitivePluginRequestFileHandle >> >> - primitivePluginRequestState >> >> - primitivePluginRequestURL >> >> - primitivePluginRequestURLStream >> >> - primitivePluginPostURL >> >> >> >> * Include sqMemoryAccess.h to have sqInt defined >> >> >> :040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 >> d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms >> >> :040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c >> 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src >> >> >> >> >> Last good commit >> >> >> commit 0b4551db2e5c00f67502250d0336757ed12ab096 >> >> Merge: f219b7218 afbf9e015 >> >> Author: Fabio Niephaus <[hidden email]> >> >> Date: Mon Jan 6 17:08:45 2020 +0100 >> >> >> Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci >> skip] >> >> >> >> Fix image MC loading glitch in image build scripts when checking pack… >> >> >> >> >> >> With the last good commit I have a working ARM COG vm. >> >> Image >> ----- >> /work/share/tmp/Squeak5.3-19431-32bit.image >> Squeak5.3 >> latest update: #19431 >> Current Change Set: HomeProject >> Image format 6521 (32 bit) >> >> Virtual Machine >> --------------- >> /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak >> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives >> VMMaker.oscog-eem.2597] >> Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 >> platform sources revision VM: 202001061608 >> :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: >> 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm >> CoInterpreter VMMaker.oscog-eem.2597 uuid: >> 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: >> 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 >> >> To Build A Similar Virtual Machine >> ---------------------------------- >> Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the >> "Clone or download" instructions, then read the top-level README.md >> and HowToBuild files in the top-level build directory for your >> platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. >> >> >> Image >> ----- >> /work/share/tmp/Squeak6.0alpha-19511-32bit.image >> Squeak6.0alpha >> latest update: #19511 >> Current Change Set: HomeProject >> Image format 6521 (32 bit) >> >> Virtual Machine >> --------------- >> /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak >> Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives >> VMMaker.oscog-eem.2597] >> Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 >> platform sources revision VM: 202001061608 >> :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: >> 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm >> CoInterpreter VMMaker.oscog-eem.2597 uuid: >> 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: >> 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 >> >> To Build A Similar Virtual Machine >> ---------------------------------- >> Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the >> "Clone or download" instructions, then read the top-level README.md >> and HowToBuild files in the top-level build directory for your >> platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc. >> >> Tiny Benchmarks >> --------------- >> 320,000,000 bytecodes/sec; 19,000,000 sends/sec >> >> >> 15 March 2020 23:39 tim Rowledge <[hidden email]> wrote: >> >> >> > On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote: >> > >> > >> > Hi, >> > >> > It looks like >> > >> > sudo apt-get install libgl1-mesa-dev >> > >> > replaces >> > >> > sudo apt-get install libgl-mesa-dev >> >> Looks like it; at least it built ok. Eventually we'll see if it works! >> >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Oxymorons: Act naturally >> >> >> >> >> >> > |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Thanks for banging on the bisect thing Bruce. I gave up yesterday when cloning the repository to my Pi was running. Well, crawling, at the time.
> On 2020-03-16, at 9:33 AM, Levente Uzonyi <[hidden email]> wrote: >> >>> Fix old bug in ARM32 LoadEffectiveAddressMwrR Looking back at a last November version of cogitARMv5.c and the implementation/translation of LoadEffectiveAddressMwrR I see that there seems now to be a missing calculation of the immediate5 and rot5 in 5259: /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5); by comparison in the (working) older file it is 5158: rot4 = 32 - i4; immediate4 = (((usqInt) offset27) >> i4) | ((offset27 << (32 - i4)) & 0xFFFFFFFFU); /* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, immediate4, ((sqInt)((usqInt)(rot4) << 1))); A bit of scanning shows immediate5 is never set, which rarely works out well... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Vacca foeda = Stupid cow |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by Levente Uzonyi
Hi, Something to remember about git bisect is that it's a binary search. You give it a working version, I chose one from 31 May 2019, and a broken one, current, and it does the binary search where it makes a checkout the current one, and, you build and test. Then you say that it's good or bad. But...... And this is very important. You have to say that a version is bad if it does not produce a working binary. The assumption is that there is one broken commit, and, therefore a binary search will work. It assumes that the problem is below, with Y means good and N means bad. YYYYYYYYYYYYYYYYNNNNNNNNN It will find the transition between Y and N correctly. If on the other hand you have something like this, again with Y is good and N is bad: YYYYYYYYYYYYYNNNNNNNNNNYYNNN It will find likely find the first transition of Y to N, not the second which is the one you want to find. It would depend totally on which start point one chooses. I can rerun bisect with a different start and see what happens. Since I'm Day Drinking, sorry, working from home, I can setup the build system next to my work computer and run it that way. cheers bruce P.S. If you want to try this at home, I do untar an existing checkout from sometime in march. build, confirm it fails. git bisect start git bisect bad git bisect good somecheckoutthatisthoughttowork Now rerun the build and check, if it's good git bisect good and if bad then git bisect bad after a few seconds it will move you to the next version to check, and, you can rebuild again. Repeat until either of the good/bad git bisect commands tells you which is the first bad checkout. cheers bruce 16 March 2020 17:33 Levente Uzonyi <[hidden email]> wrote:
|
Re: [Vm-dev] Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by timrowledge
tim Rowledge <[hidden email]> schrieb am Mo., 16. März 2020, 18:47:
After the clone, you can do (in the cloned directory) git checkout <commit-id/sha-1> And your directory will contain the tree as it was at that version. (If you want to use this clone for further work, you must go back to a branch before you create new commits: git checkout <branchname>) |
Re: [Vm-dev] Squeak5.3 linux ARMv6 segfaults on startup
|
|
It looks like sometihng caused the CogARMCompiler>>#rotateable8bitImmediate:ifTrue:ifFalse: to get translated in a way that messes up the block args for the falseBlock (which are supposed to be the requird rotation and immediate values.
What we get is /* begin rotateable8bitImmediate:ifTrue:ifFalse: */ if ((offset27 & 0xFF) == offset27) { /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord42; return 4; } for (i5 = 2; i5 <= 30; i5 += 2) { if ((offset27 & (((0xFFU << i5) & 0xFFFFFFFFU) | (((usqInt)(0xFF)) >> (32 - i5)))) == offset27) { /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord42; return 4; } } ... when we should get more like - /* begin rotateable8bitImmediate:ifTrue:ifFalse: */ if ((offset27 & 0xFF) == offset27) { /* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, offset27, 0U << 1); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord37; (self_in_dispatchConcretize->machineCodeSize) = 4; goto l204; } for (i4 = 2; i4 <= 30; i4 += 2) { if ((offset27 & (((0xFFU << i4) & 0xFFFFFFFFU) | (((usqInt) 0xFF) >> (32 - i4)))) == offset27) { >>>>>>>> rot4 = 32 - i4; <<<<<<<<<<< >>>>>>>> immediate4 = (((usqInt) offset27) >> i4) | ((offset27 << (32 - i4)) & 0xFFFFFFFFU); <<<<<<<<<<< /* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, immediate4, ((sqInt)((usqInt)(rot4) << 1))); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord37; (self_in_dispatchConcretize->machineCodeSize) = 4; goto l204; } } (ignoring for a moment the desired change in the last couple of lines) The actual code for CogARMCompiler>>#rotateable8bitImmediate:ifTrue:ifFalse: hasn't changed since 2015 so it's some other part of the system at fault. Do I recall correctly that some changes were recently made in the translator stuff for type-fiddling? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Don't diddle code to make it faster; find a better algorithm. |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by timrowledge
Hi All, apologies; this is my bug. Having revived my Raspberry 3 build machine I've just reproduced the crash and can see that it's a code generator bug. The very first JITted method executed answers SmalltalkImage current. The code generated for this should be 0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #8] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr but is alas 0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #-0] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr I have to find out why this does't fail in the simulator (or find out that it does and that my recollection of having tested 32-bit ARM recently is, in fact, a self-serving hallucination). Hopefully normal service should be restored presently. But it does mean releasing an updated Squeak5.3 release with a fixed VM. Again, apologies. On Sat, Mar 7, 2020 at 10:10 PM tim Rowledge <[hidden email]> wrote: Oh pooh. _,,,^..^,,,_ best, Eliot |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi All, interesting. Indeed the simulator generates the correct code, and the image is functional: 00001cdc: ldr r0, [pc, #8] ; 0x0000000000001cec a(n) Global 00001ce0: ldr r7, [r0, #12] 00001ce4: mov r5, r7 00001ce8: mov pc, lr So there's a Slang bug. On Tue, Mar 17, 2020 at 5:34 PM Eliot Miranda <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
On Tue, Mar 17, 2020 at 7:56 PM Eliot Miranda <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
HI, I've built with this version: commit 102b0fa831e2f793620a9a4cf94369d696e7920f Author: Eliot Miranda <[hidden email]> Date: Tue Mar 17 19:01:16 2020 -0700 CogVM source as per VMMaker.oscog-eem.2728 And it builds and runs on Arm32. Seems ok though without a giant amount of checking. Thanks!!!! cheers bruce 18 March 2020 03:58 Eliot Miranda <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like. The other tools seem to have sensible fonts. 18 March 2020 15:26 "Bruce O'Neel" <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
Hi Bruce,
On Mar 18, 2020, at 8:35 AM, Bruce O'Neel <[hidden email]> wrote:
|
Re: Squeak5.3 linux ARMv6 segfaults on startup
|
|
I've just built plain and debug on my Pi 3B+ and it works fine; no strange fonts or anything like that. TinyBenchmarks run from the About... tool gives the usual results.
The assembler problem I had been seeing the other day turns out to be a side-effect of some *really* strange CIFS network file system issue; I can no longer compiile from sources on my iMac read by the Pi using a CIFS connection setup that has worked for at least 5 years. Anyone actually knowledgable about that sort of thing? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer. |
Re: [Vm-dev] Squeak5.3 linux ARMv6 segfaults on startup
|
|
In reply to this post by Bruce O'Neel-2
> On 2020-03-18, at 8:34 AM, Bruce O'Neel <[hidden email]> wrote: > > > Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like. > > The other tools seem to have sensible fonts. Are you still seeing this? I can't replicate at all. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Half the people you know are below average. |
Re: [Vm-dev] Squeak5.3 linux ARMv6 segfaults on startup
|
|
HI, Attached is a screen shot. In all cases I'm working over X11. This screenshot is from a windows system with MobaXterm. But the XQuartz display is identical. If you don't see this one an attached display, then I would be tempted to say go with this. BTW, it looks more readable shrunk down than it does on a retina display.  cheers bruce 19 March 2020 00:18 tim Rowledge <[hidden email]> wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |