| --- Log opened Sun May 15 00:00:07 2016 | ||
| shorne | olofk: something kind of strange with these errors. | 05:05 |
|---|---|---|
| shorne | core: 4 byte read to unmapped address 0x3f800000 at 0x27bc | 05:05 |
| shorne | core: 4 byte misaligned write to address 0x6 at 0x2aac | 05:05 |
| shorne | that is in add_various_floatvecs and add_singlevecs, respectively | 05:06 |
| shorne | those 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 locations | 05:07 |
| shorne | maybe, thats just corrupt stack like you mention | 05:09 |
| shorne | I am thinking, we pass STRUCT and UNION as pointer, maybe we need to do the same for VECTOR | 05:18 |
| shorne | might as well try it | 05:19 |
| shorne | :), that worked | 05:21 |
| shorne | worked for add_singlevecs((char1) {6}, (int1) {12}, (double1) {24}), but not for | 05:22 |
| shorne | add_various_floatvecs(2, f4a, f4b) | 05:23 |
| shorne | I think because add_various_floatvecs uses varargs, we might need to write some size data onto the stack | 05:25 |
| shorne | nevermind, the size is the first value passed | 05:37 |
| olofk | shorne: Cool. Great find! | 10:55 |
| olofk | So is this true for all vectors, or just the large ones? | 10:56 |
| shorne | I think for all | 10:57 |
| shorne | but I am getting some stange issue with | 10:57 |
| shorne | print add_various_floatvecs(2, f4a, f4b) | 10:57 |
| shorne | once I get into the function it things the args are | 10:58 |
| shorne | Breakpoint 2, add_various_floatvecs (n=24688, a=...) | 10:58 |
| shorne | so 2 turns into 24688 | 10:59 |
| shorne | but we do store 2 to r3 | 10:59 |
| shorne | so, something strange there | 11:00 |
| shorne | olofk: 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 |
| shorne | ok, r3 needs passed as the return address if the function returns a struct | 12:17 |
| shorne | as per : http://www.embecosm.com/appnotes/ean3/html/ch04s02s05.html | 12:17 |
| shorne | ah, thats there implemented first | 12:18 |
| shorne | going to bed, will re-read this tomorrow | 12:19 |
| olofk | Why can't openrisc also have a simple ABI? :( | 14:01 |
| olofk | Can 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 |
| olofk | ok, variadic | 15:42 |
| olofk | arguments are always put on the stack | 15:42 |
| olofk | according the the spec | 15:42 |
| olofk | I wonder if gdb handles this | 15:44 |
| wallento | that was a massive issue with Linux programs I remember | 15:46 |
| wallento | with variadic function pointers being cast to non | 15:47 |
| olofk | Yeah, was it sdl or something that relied on the way that x86/arm did it | 15:47 |
| wallento | yeah, like xterm or so | 15:47 |
| wallento | we had the discussion at ORCONF 2013 | 15:47 |
| wallento | about changing the ABI | 15:47 |
| wallento | because it got hard to convince the upstream maintainers that these function pointer casts are illegal | 15:48 |
| wallento | but we went with not breaking legacy IIRC | 15:48 |
| olofk | I can see the problem with breaking ABI now after digging into gdb | 15:58 |
| olofk | The most correct solution would likely be to define a new ABI. MIPS have several | 15:58 |
| olofk | But I'm not sure there is enough interest in keeping several ABIs | 15:59 |
| wallento | yeah, we talked about OR2K too then | 16:01 |
| wallento | or just make 1.2, there are sufficient other extensions like 64 bit | 16:01 |
| wallento | but still needs extra maintenance | 16:02 |
| shorne | olofk: I was thinking, there might be a problem with how we are hanling the large literals. | 16:54 |
| shorne | in 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 |
| shorne | Need to confirm thats whats expected. | 16:55 |
| olofk | shorne: 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 it | 16:56 |
| olofk | Guessing probably has a higher chance of success than actually understanding the GCC code :) | 16:56 |
| shorne | Also, 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 args | 16:57 |
| olofk | I 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 at | 16:58 |
| shorne | it seems the stack is setup in the function (maybe in va_start) | 16:58 |
| olofk | good luck and good night | 16:59 |
| shorne | good night, I wont have time today. | 17:00 |
| shorne | but ill try to read what I can | 17:00 |
| shorne | guessing is probably easier. | 17:00 |
| shorne | olofk: 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 register | 17:28 |
| shorne | but something looks strange, r3=return-struct, r4=2, r5=(pointer to f2a on stack), (f2b on stack) | 17:32 |
| shorne | print add_various_floatvecs(2, f4a, f4b) | 17:33 |
| shorne | f2a/f4a | 17:33 |
| shorne | strange thing is, why doesnt it use r6 for the 3rd arg? | 17:34 |
| --- Log closed Mon May 16 00:00:08 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!