IRC logs for #openrisc Saturday, 2016-05-14

--- Log opened Sat May 14 00:00:05 2016
olofkshorne: Awesome!10:28
olofkFor the first fails, I still wonder if double is defined as something larger than 8 bytes on OpenRISC, or or1k doesn't support it at all, or if we need to add some flags to build with double support10:29
olofkbandvig: You're the FPU master. Any clues?10:29
bandvigDouble isn't implemented in hardware.10:46
bandvigA.F.A.I.K GCC is able to emit double instructions. To activate the feature the -mdouble-float option should be used.10:47
bandvigI haven't seen attentively, but it looks like GCC treat double as structure of two 32-bit words.10:47
bandvigTo load each double operand GCC uses two l.lw and than emits double instruction with register addresses containing MSBs of the operands.10:47
olofkbandvig: Hmm.. that would indicate that double should be 8 bytes (2*32-bit words)10:48
olofkprintf("%d\n", sizeof(double)); gives me 810:49
olofkSo there isn't anything yet that could explain the gdb errors10:50
bandvigolofk: could not help :( as I'm not faminiliar with gdb (as with other soft tools)10:53
olofkbandvig: No worries. Thanks for confirming that double is not implemented in hw and the mdouble-float option10:54
olofkHmm.. antgreen is not around. He implemented something related to this error in his moxie backend10:55
olofkok, so it's probably in extract_{,un}signed_integer function in gdb/findvar.c10:56
olofkmoxie and microblaze seems to override these functions for some unknown reason10:57
bandvigolofk: From message "That operation is not available on integers of more than 8 bytes." I could conclude that additionally to float/double, some other floating point formats are active.10:57
olofkbandvig: Looking at the log, all the tests that fails with this error seem to be related to doubles, while the same functions with float work10:59
bandvigPerhapse, to overcome the problem, it is possible to switch off such formats somewhere in configuration of tests.10:59
olofkhmm... it looks like many sim backends have a interp.c that overrides extract_{,un}signed_integer. Maybe we should do this or or1k sim as well10:59
olofkbandvig: Yeah, that could be an idea to see if the errors disappear, but I would like to know why they fail as well11:00
olofkok, I have confirmed now that the problem is in findvar.c:extract_unsigned_integer the len parameter is 16, but the functions breaks if it's >811:06
olofkI wonder if you can run this in gdb :)11:06
olofkCould this be related?
olofkhmmm does this test fail with or1ksim11:56
olofkoh, I give up12:07
olofkshorne: Regarding the c++ patch, I don't feel qualified to comment on that, but we have a silent ack principle for openrisc, so if no one has complained within a reasonable time (~a week), I'll apply it12:22
olofkok, so I haven't given up quite yet12:37
olofkThe call definitely comes from or1k-tdep.c12:37
olofkin or1k_push_dummy_call12:37
olofklen=16 is passed to extract_unsigned_integer which breaks it12:38
olofkBut if I have understood things correctly, len (size of variable?) should be 812:39
olofklen comes from arg_type->length, which is initialized by struct type    *arg_type = check_typedef (value_type (arg))12:40
olofkAnd that sends me deeper into gdb than I would ever hope to be12:40
olofkoh wait... in the testcase they pass vectors of values, not values12:42
olofkCould it be that those sneaky bastards are actually trying to create types that really are 16 bytes12:44
olofkhmm... is this some kind of SIMD extension stuff?12:45
olofkThat couldn't possibly supported on or1k :)12:46
olofkhmmm... but still.. most of the tests pass12:47
olofkohhh.... maybe that's what the comment says12:47
olofk"This code breaks if we can have quad-word scalars (e.g. long double)."12:48
olofkSo... this is known to not be working then? Haven't got a clue how to fix it, or even how to mark it as unsupported for larger vectors12:50
olofkNo one in their right mind would try to do arithmetics on a vector of doubles on OpenRISC12:52
olofkWhere was our gdb code mostly copied from?14:49
olofkI looked at mips, and they seem to pass larger args on the stack14:49
olofk, which makes sense of course, but I don't understand why this code should be in gdb. Isn't this a gcc/binutils/libc thing to care about?14:50
olofkOr is it that we need to make the gdb code do exactly like gcc/binutils/libc (or where this code is stored)14:50
olofkSo many questions14:50
olofkIs this some kind of ABI thing? blueCmd, stekern perhaps knows something?14:51
olofkI give up again15:00
olofkHmmm... it could be worth a shot to change the code in or1k-tdep.c to store all args > 8 bytes to the stack instead of using registers15:04
olofkUnfortunately this requires some refactoring15:04
olofkRight now we use use all registers we can and send the rest to the stack15:06
olofkI'm sure someone else understand how this works15:07
olofkAnd of course I'm not sitting alone looking at gdb on a saturday night. I'm asking for a friend15:09
olofkoh.. the ABI mentions vectors, but nothing about doubles in there15:17
olofkI give up again15:18
stekernolofk: what's the problem with what we are doing?15:23
olofkstekern: Two things. From the ABI side, it says nothing about how to handle vectors of doubles (I guess that applies to other potential 16-byte args)15:39
olofkThe other things is the code in or1k-tdep.c in gdb15:39
olofkWe first loop over all args and assign them to registers until we have run out of regs15:39
olofkAfter that there is a second loop that stores the remaining args on the stack15:40
stekernright, and why is that a problem?15:40
olofkBut I guess what I want is to push 16-byte args to the stack and then continue to use args if we have any left15:40
olofkSo if you have a function that uses (<large_sized_arg, int, int, int) we don't want the three last to end up on the stack15:41
stekernwhy not?15:42
olofkFuck should I know? :)15:42
olofkI thought we wanted to use registers as much as we can for args15:42
stekernwho says we don't then? ;)15:42
stekernI guess you could have some problems with large sized args being split over regs and stack15:45
stekernI can't remember how we handle that15:45
olofkOne big thing I can't quite figure out is if we can do whatever we want in gdb, or if we must do the same as we do in gcc15:45
stekernwell, you probably have to agree on the same ABI in gdb and gcc15:46
stekernI'd assume15:46
olofkI would assume that too15:46
olofkUnfortunately nothing in in the ABI says anything about args > 8 bytes15:46
olofkSo either we have no support in gcc, or we just did something there15:47
stekernwell, I guess what gcc does is the de facto ABI then15:47
olofkYeah, I agree15:47
olofkHaven't got a clue where to look for it though. Is it even in gcc, or hidden somewhere in binutils=15:47
stekernit should be in gcc15:48
olofkAt least that makes it few million less lines of code to look at15:48
stekernin llvm the definition just goes like this:
olofkI though of compiling a small program that passes a large arg to a function and look at the disasm15:52
olofkhaha. That was a bit less code than I had expected :)15:53
olofkBut I read that as we only handle 8,16 and 32-bit args15:53
olofkoh.. and send the rest to the stack?15:54
stekernno, the others get split (i.e. a 64-bit argument will consume 2 registers)15:57
stekerna 128-bit 4 registers15:57
olofkok. The last part is what I was looking for15:57
olofkCan you see that in the file you linked?15:58
olofkI couldn't15:58
stekernthat is what happens at least15:59
stekernif you want something else, you'd have to do something about it in:
stekern(I think, was a long time since I last looked at that)16:01
olofkI'm fine with passing 128-bit args in registers. It's just that the extract_unsigned_integer in gdb breaks on >64 bits16:02
olofkIt looks like a few arches overrides this function though16:02
olofkSo, either do that, or somehow chop it up to smaller sizes before entering the function16:03
olofkBut it would be good to verify what gcc does as well, since I most likely want to follow that16:03
olofkI think the answer could be in gcc/config/or1k/or1k.c16:05
olofkFound some related stuff there at least16:05
olofkIs a prologue the part in the beginning of a function to get stuff from the stack?16:09
olofkAnd what's a trampoline then? The related code in the calling function to setup the stack?16:09
olofkWho wrote this? Update the data in "cum"16:12
olofkHmm... so far I understand it as it does the same in gcc. Checks if there are enough registers left to save the arg16:20
olofkok, fine. Looks like most other arches just chops up large arguments in pieces before sendint to extract_unsigned_integer16:29
shorneolofk: thanks for looking into it16:33
shornewhich test are you looking at gdb.base/callfuncs.exp, gdb.base/gnu_vector.exp?16:35
shorneIt looks like its not really failing on openrisc thing, its gdb trying to find a variable in memory. Since for some reason our arch is more than 8 gdb is tripping16:40
shornelet me see what the program/assebmly is in this test.  Did you see if the test runs?16:41
shorneI mean, the code16:41
olofkI have a pretty clear view of what's going on now actually16:41
olofkThe problem is with function arguments > 8 bytes16:43
olofkIf arg size is 4, we put it into a reg if there is at least one remaining reg16:43
olofkIf args size is 8, we put it into two regs, if there are two regs left16:43
olofkBut we don't handle larger arg sizes16:44
shorneok, but the error is saying gdb is having a problem, isn't it?16:46
shorneoh, well it doesn't like gdbarch16:48
shornewhich we define16:48
olofkshorne: Are we talking about the same error? I mean the one that says "That operation is not available on integers of more than 8 bytes"16:53
shorneyeah, I mean, the code we generate seems to be valid, the test code is gnu_vector.c16:56
shornethe test is in gdb run "print add_some_intvecs(i4a, i4b, 3 * i4a)"16:56
shornein the test code, the main function calls "add_some_intvecs (i4a, i4a + i4b, i4b)"16:57
shornewhich doesnt fail if we run the code to completion, so I guess the assembly we generate is ok16:57
olofkYes, gcc seems to be good16:58
shorneThe error is coming from extract_unsigned_integer?16:59
shornein findvar16:59
olofkyep. It's not designed to handle > 8 byte args17:02
olofkBut the other arches chop up larger args into smaller pieces before entering that function17:02
shorneI see, where is it being called when it fails?17:04
shorne../../binutils-gdb/gdb/or1k-tdep.c, there are other places its called like gdb/stack.c gdb/frame.c17:05
olofkor1k_push_dummy_call in or1k-tdep.c17:05
olofkMy diff so far
olofkCurrently segfaults though.17:06
olofkThe code thing is that we will probably end up with less code and fewer corner cases when it's done17:07
shorneok, right push dummy_call that explains too since its doing a dummy call to print17:07
shorneok, let me read original code first, then ill see the patch17:09
olofkLet me know if I should explain what I know17:10
olofkshorne: Once you get a grip on the function, please tell me how the hell can be correct => sp -= ((len + bpw - 1) / bpw) * bpw;17:17
olofkoh.. it's integer division17:18
shornebpw = 4, (32-bit), len = len of arg?17:20
shorneit arg is 3 we want to, to reserve417:21
shorneir arg is 5, we want to, reserve 817:21
olofkyeah, I came to that conclusion17:21
olofkHaven't done arithmetics in C for some time and forgot integer division. Thought it was very strange that we wanted to push the stack pointer 7, 11 or 19 bytes :)17:22
shorneyes, it looks alright to me17:23
shorneinteresting that they have a comment saying, "here allows for future long double"17:27
shornebut above they said they dont support, so whoever wrote it expected to implement long double. This is all from or1k-src17:28
olofkYeah, I saw that too17:29
olofkJob was half done :)17:30
olofkIt's getting late here, but I think I should be pretty close17:32
olofkThe thing that fails for me now seems to be with registers that are pushed to the stack17:34
shornewhere that gdb_assert is... you are getting SEGV there?17:38
olofkI get the same number of fails with or without the assert, so I assume the problem is with args > 8 bytes that are pushed to the stack17:39
shorneI see, they sont seem to support larger args there17:39
olofkBut I thought I had fixed that now17:39
shornethe assert should throw some error if len is > than 8?  But I guess its not?17:41
olofkThe assert catches correctly17:41
olofkBut I'm trying to remove this limitation now, so that it can handle len > 817:41
olofkAnd therefore I'm removing the assert as well17:42
shorneright, so you split into 4 byte writes17:42
olofkI've been looking at the nios code now17:42
olofkBut we need to do it slighly different17:43
olofknios (and most other arches) can split large arguments between register and the stack17:43
olofkBut openrisc apparently doesn't17:43
shorneI see, whats failing in your current patch?17:46
shorneit looks ok at first glance17:46
olofkI think I'm corrupting the stack17:48
shornecore: 4 byte misaligned write to address 0x6 at 0x2ad8?17:48
olofkYeah, that's not good17:49
shorneYeah, strange though, I saw this same error in other places (with the address 0x6)17:49
olofkDropping this for now, but here's the latest version of my function17:50
olofk103 pass and 10 fail for gnu_vector17:51
olofkAnd all fails seem to be during tests with large args or a large number of small args, which leads me to believe that I'm not setting up the stack correctly17:51
olofkGood night17:52
shornethanks, good night17:52
shorneI see, maybe I saw these errors before because they were there before. Your code (and before) adjusts the stack after the initial write17:55
shornemaybe we need to properly align before we right17:55
shornehaha, align_up (of course, there already is a function for that integer math)17:57
shorneno... but by the time we get there for the first time stack_offset would be 018:07
shornemaybe this code is working, and the failure is somewhere else18:15
--- Log closed Sun May 15 00:00:07 2016

Generated by 2.15.2 by Marius Gedminas - find it at!