|
01:43
Kaiepi joined
02:40
lizmat joined
02:56
ilbot3 joined
04:22
harrow joined
04:36
p6lert joined
07:10
domidumont joined
08:10
robertle joined
08:14
domidumont joined
09:29
Ven`` joined
09:56
nebuchadnezzar joined
10:38
nebuchadnezzar joined
11:05
Voldenet joined
|
|||
| domidumont | Hi, Is anyone looking at moar bus error on armhf ? github.com/perl6/nqp/issues/431 . | 11:55 | |
|
12:11
nebuchad` joined
12:15
lizmat joined
12:16
nebuchadnezzar joined
|
|||
| 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) | |||
|
12:56
Ven`` joined
12:59
AlexDaniel joined
|
|||
| domidumont | good point.. | 13:13 | |
| FTR, armhf is a 32 bits arch, so it should be aligned on 4 bytes | 13:17 | ||
|
13:39
Voldenet joined
|
|||
| 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 | |
|
16:26
FROGGS joined
|
|||
| 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 | ||
|
17:15
robertle joined
|
|||
| 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 | ||
|
17:32
domidumont joined
|
|||
| 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 | |
|
19:39
domidumont joined
19:41
robertle joined
21:41
lizmat joined
23:38
lizmat joined
|
|||