IRC logs for #openrisc Sunday, 2016-05-15

--- Log opened Sun May 15 00:00:07 2016
shorneolofk: something kind of strange with these errors.05:05
shornecore: 4 byte read to unmapped address 0x3f800000 at 0x27bc05:05
shornecore: 4 byte misaligned write to address 0x6 at 0x2aac05:05
shornethat is in add_various_floatvecs and add_singlevecs, respectively05:06
shornethose values, 0x3f80.. and 0x6 are the literal arguments written to regs/stack.  But the code is trying to access them as if they are memory locations05:07
shornemaybe, thats just corrupt stack like you mention05:09
shorneI am thinking, we pass STRUCT and UNION as pointer, maybe we need to do the same for VECTOR05:18
shornemight as well try it05:19
shorne:), that worked05:21
shorneworked for add_singlevecs((char1) {6}, (int1) {12}, (double1) {24}), but not for05:22
shorneadd_various_floatvecs(2, f4a, f4b)05:23
shorneI think because add_various_floatvecs uses varargs, we might need to write some size data onto the stack05:25
shornenevermind, the size is the first value passed05:37
olofkshorne: Cool. Great find!10:55
olofkSo is this true for all vectors, or just the large ones?10:56
shorneI think for all10:57
shornebut I am getting some stange issue with10:57
shorneprint add_various_floatvecs(2, f4a, f4b)10:57
shorneonce I get into the function it things the args are10:58
shorneBreakpoint 2, add_various_floatvecs (n=24688, a=...)10:58
shorneso 2 turns into 2468810:59
shornebut we do store 2 to r310:59
shorneso, something strange there11:00
shorneolofk: I dont have any patch to share, I didnt get much time today.  Right now I am just looking at the function which is failing to understand how it expects to get the args.11:54
shorneok, r3 needs passed as the return address if the function returns a struct12:17
shorneas per :
shorneah, thats there implemented first12:18
shornegoing to bed, will re-read this tomorrow12:19
olofkWhy can't openrisc also have a simple ABI? :(14:01
olofkCan someone enlighten me on how varargs are split between regs and stack. I remember there was some discussion about that some time ago ( blueCmd, stekern ?)14:58
olofkok, variadic15:42
olofkarguments are always put on the stack15:42
olofkaccording the the spec15:42
olofkI wonder if gdb handles this15:44
wallentothat was a massive issue with Linux programs I remember15:46
wallentowith variadic function pointers being cast to non15:47
olofkYeah, was it sdl or something that relied on the way that x86/arm did it15:47
wallentoyeah, like xterm or so15:47
wallentowe had the discussion at ORCONF 201315:47
wallentoabout changing the ABI15:47
wallentobecause it got hard to convince the upstream maintainers that these function pointer casts are illegal15:48
wallentobut we went with not breaking legacy IIRC15:48
olofkI can see the problem with breaking ABI now after digging into gdb15:58
olofkThe most correct solution would likely be to define a new ABI. MIPS have several15:58
olofkBut I'm not sure there is enough interest in keeping several ABIs15:59
wallentoyeah, we talked about OR2K too then16:01
wallentoor just make 1.2, there are sufficient other extensions like 64 bit16:01
wallentobut still needs extra maintenance16:02
shorneolofk: I was thinking, there might be a problem with how we are hanling the large literals.16:54
shornein the docs it says anything over 64bit will be bassed as address. So instead of splitting it maybe we just send the address.16:55
shorneNeed to confirm thats whats expected.16:55
olofkshorne: Yeah. It's a problem that it's not really in the spec, so it's mostly a guessing game to see how gcc does it16:56
olofkGuessing probably has a higher chance of success than actually understanding the GCC code :)16:56
shorneAlso, in terms of varargs.  Reading throuhg it (the assembly generated by the function) yesterday, the argument pointers are put on the stack in order, then a stack pointer iterator is used to iterate through the args16:57
olofkI still think we're pretty close, but I couldn't find much time to look at it today. I'll give it another shot tomorrow. Let me know if you have any code you want me to look at16:58
shorneit seems the stack is setup in the function (maybe in va_start)16:58
olofkgood luck and good night16:59
shornegood night, I wont have time today.17:00
shornebut ill try to read what I can17:00
shorneguessing is probably easier.17:00
shorneolofk: reading the assembly, its a bit different from what I said, for the vectors we slice the data to the stack, then put a pointer to the stack in the register17:28
shornebut something looks strange, r3=return-struct, r4=2, r5=(pointer to f2a on stack), (f2b on stack)17:32
shorneprint add_various_floatvecs(2, f4a, f4b)17:33
shornestrange thing is, why doesnt it use r6 for the 3rd arg?17:34
--- Log closed Mon May 16 00:00:08 2016

Generated by 2.15.2 by Marius Gedminas - find it at!