| --- Log opened Sat May 14 00:00:05 2016 | ||
| olofk | shorne: Awesome! | 10:28 |
|---|---|---|
| olofk | For 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 support | 10:29 |
| olofk | bandvig: You're the FPU master. Any clues? | 10:29 |
| bandvig | Double isn't implemented in hardware. | 10:46 |
| bandvig | A.F.A.I.K GCC is able to emit double instructions. To activate the feature the -mdouble-float option should be used. | 10:47 |
| bandvig | I haven't seen attentively, but it looks like GCC treat double as structure of two 32-bit words. | 10:47 |
| bandvig | To load each double operand GCC uses two l.lw and than emits double instruction with register addresses containing MSBs of the operands. | 10:47 |
| olofk | bandvig: Hmm.. that would indicate that double should be 8 bytes (2*32-bit words) | 10:48 |
| olofk | printf("%d\n", sizeof(double)); gives me 8 | 10:49 |
| olofk | So there isn't anything yet that could explain the gdb errors | 10:50 |
| bandvig | olofk: could not help :( as I'm not faminiliar with gdb (as with other soft tools) | 10:53 |
| olofk | bandvig: No worries. Thanks for confirming that double is not implemented in hw and the mdouble-float option | 10:54 |
| olofk | Hmm.. antgreen is not around. He implemented something related to this error in his moxie backend | 10:55 |
| olofk | ok, so it's probably in extract_{,un}signed_integer function in gdb/findvar.c | 10:56 |
| olofk | moxie and microblaze seems to override these functions for some unknown reason | 10:57 |
| bandvig | olofk: 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 |
| olofk | bandvig: Looking at the log, all the tests that fails with this error seem to be related to doubles, while the same functions with float work | 10:59 |
| bandvig | Perhapse, to overcome the problem, it is possible to switch off such formats somewhere in configuration of tests. | 10:59 |
| olofk | hmm... 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 well | 10:59 |
| olofk | bandvig: Yeah, that could be an idea to see if the errors disappear, but I would like to know why they fail as well | 11:00 |
| olofk | ok, 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 >8 | 11:06 |
| olofk | I wonder if you can run this in gdb :) | 11:06 |
| olofk | Could this be related? https://github.com/openrisc/binutils-gdb/blob/or1k/gdb/or1k-tdep.c#L1276 | 11:13 |
| olofk | hmmm does this test fail with or1ksim | 11:56 |
| olofk | oh, I give up | 12:07 |
| olofk | shorne: 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 it | 12:22 |
| olofk | ok, so I haven't given up quite yet | 12:37 |
| olofk | The call definitely comes from or1k-tdep.c | 12:37 |
| olofk | in or1k_push_dummy_call | 12:37 |
| olofk | len=16 is passed to extract_unsigned_integer which breaks it | 12:38 |
| olofk | But if I have understood things correctly, len (size of variable?) should be 8 | 12:39 |
| olofk | len comes from arg_type->length, which is initialized by struct type *arg_type = check_typedef (value_type (arg)) | 12:40 |
| olofk | And that sends me deeper into gdb than I would ever hope to be | 12:40 |
| olofk | oh wait... in the testcase they pass vectors of values, not values | 12:42 |
| olofk | Could it be that those sneaky bastards are actually trying to create types that really are 16 bytes | 12:44 |
| olofk | hmm... is this some kind of SIMD extension stuff? | 12:45 |
| olofk | https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html | 12:45 |
| olofk | That couldn't possibly supported on or1k :) | 12:46 |
| olofk | hmmm... but still.. most of the tests pass | 12:47 |
| olofk | ohhh.... maybe that's what the comment says | 12:47 |
| olofk | "This code breaks if we can have quad-word scalars (e.g. long double)." | 12:48 |
| olofk | So... 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 vectors | 12:50 |
| olofk | No one in their right mind would try to do arithmetics on a vector of doubles on OpenRISC | 12:52 |
| olofk | Where was our gdb code mostly copied from? | 14:49 |
| olofk | I looked at mips, and they seem to pass larger args on the stack | 14: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 |
| olofk | Or is it that we need to make the gdb code do exactly like gcc/binutils/libc (or where this code is stored) | 14:50 |
| olofk | So many questions | 14:50 |
| olofk | Is this some kind of ABI thing? blueCmd, stekern perhaps knows something? | 14:51 |
| olofk | I give up again | 15:00 |
| olofk | Hmmm... 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 registers | 15:04 |
| olofk | Unfortunately this requires some refactoring | 15:04 |
| olofk | Right now we use use all registers we can and send the rest to the stack | 15:06 |
| olofk | I'm sure someone else understand how this works | 15:07 |
| olofk | And of course I'm not sitting alone looking at gdb on a saturday night. I'm asking for a friend | 15:09 |
| olofk | oh.. the ABI mentions vectors, but nothing about doubles in there | 15:17 |
| olofk | I give up again | 15:18 |
| stekern | olofk: what's the problem with what we are doing? | 15:23 |
| olofk | stekern: 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 |
| olofk | The other things is the code in or1k-tdep.c in gdb | 15:39 |
| olofk | We first loop over all args and assign them to registers until we have run out of regs | 15:39 |
| olofk | After that there is a second loop that stores the remaining args on the stack | 15:40 |
| stekern | right, and why is that a problem? | 15:40 |
| olofk | But I guess what I want is to push 16-byte args to the stack and then continue to use args if we have any left | 15:40 |
| olofk | So 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 stack | 15:41 |
| stekern | why not? | 15:42 |
| olofk | Fuck should I know? :) | 15:42 |
| olofk | I thought we wanted to use registers as much as we can for args | 15:42 |
| stekern | who says we don't then? ;) | 15:42 |
| stekern | I guess you could have some problems with large sized args being split over regs and stack | 15:45 |
| stekern | I can't remember how we handle that | 15:45 |
| olofk | One 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 gcc | 15:45 |
| stekern | well, you probably have to agree on the same ABI in gdb and gcc | 15:46 |
| stekern | I'd assume | 15:46 |
| olofk | I would assume that too | 15:46 |
| olofk | Unfortunately nothing in in the ABI says anything about args > 8 bytes | 15:46 |
| olofk | So either we have no support in gcc, or we just did something there | 15:47 |
| stekern | well, I guess what gcc does is the de facto ABI then | 15:47 |
| olofk | Yeah, I agree | 15:47 |
| olofk | Haven't got a clue where to look for it though. Is it even in gcc, or hidden somewhere in binutils= | 15:47 |
| olofk | ? | 15:47 |
| stekern | it should be in gcc | 15:48 |
| olofk | At least that makes it few million less lines of code to look at | 15:48 |
| stekern | in llvm the definition just goes like this: https://github.com/openrisc/llvm-or1k/blob/master/lib/Target/OR1K/OR1KCallingConv.td | 15:52 |
| olofk | I though of compiling a small program that passes a large arg to a function and look at the disasm | 15:52 |
| olofk | haha. That was a bit less code than I had expected :) | 15:53 |
| olofk | But I read that as we only handle 8,16 and 32-bit args | 15:53 |
| olofk | oh.. and send the rest to the stack? | 15:54 |
| stekern | no, the others get split (i.e. a 64-bit argument will consume 2 registers) | 15:57 |
| stekern | a 128-bit 4 registers | 15:57 |
| olofk | ok. The last part is what I was looking for | 15:57 |
| olofk | Can you see that in the file you linked? | 15:58 |
| olofk | I couldn't | 15:58 |
| stekern | that is what happens at least | 15:59 |
| olofk | k | 15:59 |
| stekern | if you want something else, you'd have to do something about it in: https://github.com/openrisc/llvm-or1k/blob/master/lib/Target/OR1K/OR1KISelLowering.cpp#L409 | 16:01 |
| stekern | (I think, was a long time since I last looked at that) | 16:01 |
| olofk | I'm fine with passing 128-bit args in registers. It's just that the extract_unsigned_integer in gdb breaks on >64 bits | 16:02 |
| olofk | It looks like a few arches overrides this function though | 16:02 |
| olofk | So, either do that, or somehow chop it up to smaller sizes before entering the function | 16:03 |
| olofk | But it would be good to verify what gcc does as well, since I most likely want to follow that | 16:03 |
| olofk | I think the answer could be in gcc/config/or1k/or1k.c | 16:05 |
| olofk | Found some related stuff there at least | 16:05 |
| olofk | https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.c#L1737 | 16:07 |
| olofk | Is a prologue the part in the beginning of a function to get stuff from the stack? | 16:09 |
| olofk | And what's a trampoline then? The related code in the calling function to setup the stack? | 16:09 |
| olofk | Who wrote this? Update the data in "cum" | 16:12 |
| olofk | Hmm... so far I understand it as it does the same in gcc. Checks if there are enough registers left to save the arg | 16:20 |
| olofk | ok, fine. Looks like most other arches just chops up large arguments in pieces before sendint to extract_unsigned_integer | 16:29 |
| shorne | olofk: thanks for looking into it | 16:33 |
| shorne | which test are you looking at gdb.base/callfuncs.exp, gdb.base/gnu_vector.exp? | 16:35 |
| olofk | gnu_vector | 16:36 |
| shorne | It 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 tripping | 16:40 |
| shorne | let me see what the program/assebmly is in this test. Did you see if the test runs? | 16:41 |
| shorne | I mean, the code | 16:41 |
| olofk | I have a pretty clear view of what's going on now actually | 16:41 |
| olofk | The problem is with function arguments > 8 bytes | 16:43 |
| olofk | If arg size is 4, we put it into a reg if there is at least one remaining reg | 16:43 |
| olofk | If args size is 8, we put it into two regs, if there are two regs left | 16:43 |
| olofk | But we don't handle larger arg sizes | 16:44 |
| shorne | ok, but the error is saying gdb is having a problem, isn't it? | 16:46 |
| shorne | oh, well it doesn't like gdbarch | 16:48 |
| shorne | which we define | 16:48 |
| olofk | shorne: 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 |
| shorne | yeah, I mean, the code we generate seems to be valid, the test code is gnu_vector.c | 16:56 |
| shorne | the test is in gdb run "print add_some_intvecs(i4a, i4b, 3 * i4a)" | 16:56 |
| shorne | in the test code, the main function calls "add_some_intvecs (i4a, i4a + i4b, i4b)" | 16:57 |
| shorne | which doesnt fail if we run the code to completion, so I guess the assembly we generate is ok | 16:57 |
| olofk | Yes, gcc seems to be good | 16:58 |
| shorne | The error is coming from extract_unsigned_integer? | 16:59 |
| shorne | in findvar | 16:59 |
| olofk | yep. It's not designed to handle > 8 byte args | 17:02 |
| olofk | But the other arches chop up larger args into smaller pieces before entering that function | 17:02 |
| shorne | I 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.c | 17:05 |
| olofk | or1k_push_dummy_call in or1k-tdep.c | 17:05 |
| olofk | My diff so far http://ef55c47becf83a24.paste.se/ | 17:06 |
| olofk | Currently segfaults though. | 17:06 |
| olofk | The code thing is that we will probably end up with less code and fewer corner cases when it's done | 17:07 |
| shorne | ok, right push dummy_call that explains too since its doing a dummy call to print | 17:07 |
| shorne | ok, let me read original code first, then ill see the patch | 17:09 |
| olofk | Let me know if I should explain what I know | 17:10 |
| olofk | shorne: 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 |
| olofk | oh.. it's integer division | 17:18 |
| shorne | alright | 17:19 |
| shorne | bpw = 4, (32-bit), len = len of arg? | 17:20 |
| shorne | it arg is 3 we want to, to reserve4 | 17:21 |
| shorne | ir arg is 5, we want to, reserve 8 | 17:21 |
| olofk | yeah, I came to that conclusion | 17:21 |
| olofk | Haven'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 |
| shorne | yes, it looks alright to me | 17:23 |
| shorne | interesting that they have a comment saying, "here allows for future long double" | 17:27 |
| shorne | but above they said they dont support, so whoever wrote it expected to implement long double. This is all from or1k-src | 17:28 |
| olofk | Yeah, I saw that too | 17:29 |
| olofk | Job was half done :) | 17:30 |
| olofk | It's getting late here, but I think I should be pretty close | 17:32 |
| olofk | The thing that fails for me now seems to be with registers that are pushed to the stack | 17:34 |
| shorne | where that gdb_assert is... you are getting SEGV there? | 17:38 |
| olofk | I 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 stack | 17:39 |
| shorne | I see, they sont seem to support larger args there | 17:39 |
| olofk | But I thought I had fixed that now | 17:39 |
| shorne | the assert should throw some error if len is > than 8? But I guess its not? | 17:41 |
| olofk | The assert catches correctly | 17:41 |
| olofk | But I'm trying to remove this limitation now, so that it can handle len > 8 | 17:41 |
| olofk | And therefore I'm removing the assert as well | 17:42 |
| shorne | right, so you split into 4 byte writes | 17:42 |
| olofk | exactly | 17:42 |
| olofk | I've been looking at the nios code now | 17:42 |
| olofk | But we need to do it slighly different | 17:43 |
| olofk | nios (and most other arches) can split large arguments between register and the stack | 17:43 |
| olofk | But openrisc apparently doesn't | 17:43 |
| shorne | I see, whats failing in your current patch? | 17:46 |
| shorne | it looks ok at first glance | 17:46 |
| olofk | http://24b5e5b1aea38105.paste.se/ | 17:48 |
| olofk | I think I'm corrupting the stack | 17:48 |
| shorne | core: 4 byte misaligned write to address 0x6 at 0x2ad8? | 17:48 |
| olofk | Yeah, that's not good | 17:49 |
| shorne | Yeah, strange though, I saw this same error in other places (with the address 0x6) | 17:49 |
| olofk | Dropping this for now, but here's the latest version of my function | 17:50 |
| olofk | http://2c5c2ffeb11d3352.paste.se/ | 17:50 |
| olofk | 103 pass and 10 fail for gnu_vector | 17:51 |
| olofk | And 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 correctly | 17:51 |
| olofk | Good night | 17:52 |
| shorne | thanks, good night | 17:52 |
| shorne | I see, maybe I saw these errors before because they were there before. Your code (and before) adjusts the stack after the initial write | 17:55 |
| shorne | maybe we need to properly align before we right | 17:55 |
| shorne | write | 17:55 |
| shorne | haha, align_up (of course, there already is a function for that integer math) | 17:57 |
| shorne | no... but by the time we get there for the first time stack_offset would be 0 | 18:07 |
| shorne | maybe this code is working, and the failure is somewhere else | 18:15 |
| --- Log closed Sun May 15 00:00:07 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!