IRC logs for #openrisc Thursday, 2017-08-10

--- Log opened Thu Aug 10 00:00:53 2017
mithroshorne: Should a divide by zero exception work in the or1k qemu?05:23
mithroI'm pretty sure the following ASM (from the code at should cause a divide by zero exception?05:38
mithroDo I have to do something special to "turn on" the exception handling?05:46
mithroLooks like I need a mtspr(SPR_SR, mfspr(SPR_SR) | SPR_SR_OVE); to enable that...06:33
mithroshorne: Did you have a fix for this error?06:46
mithro../../gdb/or1k-tdep.c:1017: internal-error: or1k_skip_prologue: Assertion `or1k_analyse_l_addi (inst, &rd, &ra, &simm) && (OR1K_FP_REGNUM == rd) && (OR1K_SP_REGNUM == ra) && (simm == frame_size)' failed.06:46
mithroHrm, should the mor1k fail on an unaligned access?07:34
shornemithro: Both should cause exception vectors07:46
shorneI have never run into those errors07:46
shorne(if the vectors are enabled)07:47
mithroshorne: After enabling the SPR_SR_OVE I get an exception on the div by zero ->
shorneOverflow flag Exception07:47
shorneexception 0x60007:48
shorneLoad/store access to naturally not aligned location.07:48
shorneexception 0xB00, for range exception (includes overflow)07:49
mithroshorne: But I'm not getting an exception on not aligned... should work right?07:50
shorneits saying "Unhandled exception 11"07:51
shorneis that the same as B00?  1<<1107:51
mithroshorne: I assume so, that exception 11 is when I do a div/007:53
shorneno thats, 80007:53
shorne11 is B though07:54
shorneIs qemu printing unhandled exception 11?07:54
shorneI guess so07:54
mithroshorne: No, our exception handler is07:55
shorneEXCP_RANGE    = 0xb,07:56
shorneI see... sorry I was just rambling looking at things07:58
shorneI am guessing this code will cause the unaligned access08:00
shornechar a[5];08:00
shorneint *b = (int *)&a[1];08:00
mithroOur exception vectors are setup at
mithroshorne: Yeah, that is what I thought, but it just seems to continuing straight past it without any issues...08:01
shornethats a 32-bit access at a[1]08:01
shornewhat does the assembly look like?08:01
shorneI see, one thing that might break gdb is how you setup the stack for the function call08:04
shornegdb is trying to look at the code in the prolog to find certain stack details like frame size, return address08:05
shorneit scans for an add before the return address08:06
shorne(I think... maybe I have a fix for this gdb Assert failure)08:06
shornemithro: yes, I have fixed that gdb issue in my branch here08:08
shorneThe actual fix is merged into the or1k-tdep.c config (but basically I just bail out of the stack trace instead of failing the assert)08:08
shorneBut your handler looks like it will work, just strange the unaligned access is not failing08:09
shorneMaybe a qemu quirk?08:10
shorneGot to go08:10
mithroshorne: Your branch doesn't seem to compile...
shornemithro: let me see, I think that function is coming from another part of binutils09:10
shorneno, you are right, I need to push that change to my branch09:15
shornemithro: I updated sorry about that, I have put gdb on my backburner while working on the linux stuff09:16
mithroshorne: I'm hoping to get back to my Linux+QEMU stuff shortly09:22
shornemithro: for linux SMP, I have a few more cleanups to do, then it should be ready for review09:24
shorne1. atomic ops only support 32-bit right now, will pull generic code out of mips/sh and use for openrisc to handle 1/2 byte ops09:25
shorne2. update cpuinfo printing to use the generic cache framework09:26
shorne3. unhacky way to fix timer sync issue (previous attempt to use a sync method didnt work due to what looks like a cache sync issue)09:27
shorne4. clean up all of the commit messages09:27
shorne.... Then also need to09:28
shorne 1. clean up my smp qemu patches for upstreaming09:28
shorne 2. update openrisc architecture spec to describe the things not documented09:29
-!- ZipCPU_ is now known as ZipCPU15:53
mithroIs anyone here able to explain NASTI in RISC-V?16:57
imphilmithro, it's just AXI renamed afaik17:12
-!- andrzejr_ is now known as andrzejr22:19
--- Log closed Fri Aug 11 00:00:54 2017

Generated by 2.15.2 by Marius Gedminas - find it at!