domidumont Hi, Is anyone looking at moar bus error on armhf ? github.com/perl6/nqp/issues/431 . 11:55
nwc10 not that I'm aware of (and I have neither harware nore time) but I see this 12:38
#0 set_num (tc=0x1db1758, st=0x1de51e0, root=<optimized out>, data=0xb5081185, value=34) at src/6model/reprs/P6num.c:54
and "...85" is a bit "WTF?" - surely that should be aligned (and I assume 8-byte aligned)
domidumont good point.. 13:13
FTR, armhf is a 32 bits arch, so it should be aligned on 4 bytes 13:17
nine In github.com/MoarVM/MoarVM/issues/762 data is also not aligned to 4 bytes 14:16
And root isn't either
timotimo well, data is a pointer into the object, usually directly after the header, unless it's inlined into a P6opaque 15:06
but i thought we inline roots, i.e. the actual object's header
er 15:16
align, not inline
dogbert11 timotimo: have a profiler SEGV if you're interested 15:18
timotimo OK, hit me
no guarantee i can do anything today, i don't feel all there today 15:20
dogbert11 gist.github.com/dogbert17/750ffbf9...72b70779d8
not the largest program eve 15:21
*ever
if you can confirm the SEGV I could create a bug report instead
timotimo cool, immediately reproduced
dogbert11 :)
do you want the bug report in the MoarVM repo or somewhere else? 15:25
timotimo well, i'm seeing the invalid assignment now, maybe it'll be a quick fix 15:29
dogbert11 do you want a bug report 15:30
timotimo ask me again in three hours :) 15:31
dogbert11 thought it might look good if you have to report to someone :) 15:32
dogbert11 notes that building Rakudo on RPi 2 is not a speedy process 15:34
timotimo yeah :( 15:37
i'm looking at something that seemingly contradicts itself 15:38
dogbert11 that sounds suspicious
timotimo oh, now it's totally different. what? 15:40
dogbert11 timotimo: turning off spesh makes the SEGV disappear 15:41
timotimo yes, i just tested that
i have a suspicion
domidumont that it's a speshific problem ? 15:42
dogbert11 :)
timotimo it wasn't the thing i thought it would turn out to be, not immediately 15:50
dogbert11 where have all the simple bugs gone 15:52
jnthn gone to fixes and spectests 15:57
timotimo gone to the roasty pasture 16:50
i find myself wishing for the "never deallocate nurseries" mode so objects can be followed all the way back to where they were created 17:12
though surely the ram usage would be quite massive 17:13
nwc10 I see that domidumont has gone, but I have this possibly inaccurate memory that on ARM double precision values have to be 8 byte aligned 17:28
timotimo oh, that could very well be
nwc10 and as the bug is reported for the "hard float" ABI this might be a requirement of the (real) FPU, whereas the emulated version can get away with 4 byte alignment 17:29
timotimo we should be able to implement that by putting in 1.5x as much space into the struct and making accesses "right" everywhere
we might also have to do this for num registers?
nwc10 I don't know and my small assistant is distracting me
domidumont this may shed some light regarding unaligned access and floating point: jsolano.net/2012/09/06/arm-unalign...-in-linux/ 17:44
timotimo float (IEEE single precission, 32-bit). ARM processor cores do not support unaligned accesses to VFP hardware instructions. See below. 18:00
teh interesting bit starts here?
domidumont The blog finishes with: "The definitive solution to this kind of abort and the one we should always aim at involves fixing our software to always access floating point data on 4-byte aligned memory." 18:28

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!