If one has any Pi model it is best to use the default flags wrt architecture when compiling C; that way it will run on any Pi from the original (I still have a working example!) to a Pi 4 (when running the default Raspbian 32bit release). When the ARMv8/AARCH64 VM is released we will have a quite different set of issues to enjoy fixing.

> On 2020-03-11, at 11:48 AM, Bruce O'Neel <bruce.oneel at pckswarms.ch> wrote:
> 
> 
> I'm willing to do PI builds but for ARMv7 not v6.
> 
> cheers
> 
> bruce
> 
> 
> 11 March 2020 19:20 tim Rowledge <tim at rowledge.org> wrote:
> Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
> 
> > On 2020-03-11, at 11:08 AM, Nicolas Cellier wrote:
> >
> > My bad, it sounds OK for armV8, not so for v6...
> > https://docs.travis-ci.com/user/multi-cpu-architectures/
> >
> > Le mer. 11 mars 2020 à 11:43, Nicolas Cellier a écrit :
> > I'm not uptodate, it seems that Travis has more to offer:
> > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
> >
> > Le mer. 11 mars 2020 à 11:38, Nicolas Cellier a écrit :
> > From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
> >
> > - we compile with gcc
> > gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
> > - it is a rather old version
> > $ gcc --version
> > gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
> >
> > - we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
> >
> >
> > Le mer. 11 mars 2020 à 08:39, Nicolas Cellier a écrit :
> > Hi,
> > I have simulated the VM (nightly, it's too long),
> >
> > | cos |
> > cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit
> > ObjectMemory Spur32BitCoMemoryManager
> > ISA ARMv5 ).
> > cos desiredNumStackPages: 8.
> > cos openOn: 'Squeak5.3-19431-32bit.image'.
> > cos openAsMorph; run
> >
> > It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
> >
> > Could the crash be related to the cross-compiler?
> > Is it gcc or clang currently for ARM builds?
> > On macos, -fsanitize=undefined notices a few unaligned memory access...
> > Could it be a clue?
> >
> >
> > Le lun. 9 mars 2020 à 02:17, tim Rowledge a écrit :
> >
> >
> > > On 2020-03-08, at 12:12 PM, tim Rowledge wrote:
> > >
> > > From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
> >
> > OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Don't document the program; program the document.
> >
> >
> >
> >
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- A one-bit brain with a parity error.
> 
> 
> 
> 
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Common sense – so rare it’s a goddam superpower