| --- Log opened Mon May 16 00:00:08 2016 | ||
| stekern | yeah, educated guessing by writing small tests and looking at the asm is probably the easiest way to figure out what gcc does | 01:21 |
|---|---|---|
| stekern | I did a lot of that when working on the llvm backend | 01:22 |
| shorne | stekern: thats right, I can then compare with gcc and the arch docs to learn it. | 05:04 |
| shorne | olofk: not sure if you saw this but there is a patch for the ABI break/fix https://github.com/openrisc/or1k-gcc/commit/f4c6fc51c0b7f44f645a4c4032252ba587cd3161 | 05:04 |
| shorne | There is a mail thread about it too. http://openrisc.2316802.n4.nabble.com/OpenRISC-Changing-the-ABI-Treat-variadic-functions-like-ordinary-C-functions-td4641575.html | 05:06 |
| shorne | I am not clear sure what Sebastian means is broken with the varags causing varargs code to need patches to run on openrisc | 05:08 |
| shorne | Nice: I found details in an archive here: https://www.mail-archive.com/openrisc@lists.openrisc.net/msg01216.html | 05:10 |
| shorne | For record: in summary, typdef for function pointer is varargs, but funtion points to a fixed arg function. Because openrisc ABI is different for vararg and non vararg it breaks. | 05:16 |
| shorne | But.. that shouldn't break this test case in gnu_vector | 05:17 |
| shorne | unless, there is no way for us to know we are calling a variadic function when preparing the dummy_call. | 05:18 |
| stekern | shorne: yes, but in the end we opted to not change the ABI, since only code with broken assumptions about varargs breaks | 06:09 |
| shorne | stekern: yeah, so the issue we are facing with gdb may be this issue if we cant determine the function we are calling in variadic | 07:36 |
| stekern | oh | 07:37 |
| stekern | that might indeed be tricky | 07:37 |
| olofk | hmm... | 07:40 |
| olofk | I have a faint memory of some flag that was set for the first vararg. Could remember it wrong, though | 07:43 |
| shorne | where is 'struct value' and 'TYPE_CODE_STRUCT' defined? | 07:44 |
| shorne | hmm, the "struct value *function" arg is never looked at | 07:47 |
| shorne | maybe something in there | 07:47 |
| olofk | Found this in another -tdep file if (TYPE_VARARGS (func_type)) | 07:48 |
| olofk | So it looks like we can detect if we're looking at an varargs function | 07:52 |
| shorne | found TYPE_CODEs in binutils-gdb/gdb/gdbtypes.h | 07:53 |
| shorne | ok, cool | 07:53 |
| olofk | Still not sure I understand the difference in the calling conventions though | 07:58 |
| shorne | Yeah, me too, still working on understanding it, I think what you implemented is the non variadic case, but for variadic function its different :) | 08:16 |
| stekern | olofk: normal functions => use regs for args, varargs = pass all varargs on stack (even if there would be free registers to pass them in) | 08:17 |
| olofk | stekern: Ah ok. But does the same rules regarding by-reference/by-value apply as for normal functions? | 11:10 |
| olofk | Because then we would only have to break the first loop directly if it's a varargs function | 11:10 |
| stekern | olofk: umm, not sure what you are asking | 11:14 |
| olofk | stekern: Maybe I misunderstood, but my understanding is that structs and unions are put somewhere and that the argument that is passed (either in stack or registers) is a pointer to the struct | 11:16 |
| stekern | right | 11:16 |
| olofk | But for ints and smaller types the value is put in the register/stack | 11:16 |
| stekern | right | 11:16 |
| olofk | Just wanted to make sure that there aren't any additional rules regarding varargs, such as even ints are passed by reference | 11:17 |
| stekern | ah, no | 11:17 |
| olofk | cool | 11:17 |
| olofk | Didn't think so either, but am treading carefully now :) | 11:18 |
| stekern | that's wise ;) | 11:56 |
| olofk | hm... I got the impression that shorne got | 12:09 |
| olofk | some changes regarding large args | 12:09 |
| olofk | Can you just run the testcases in gdb manually? | 12:55 |
| stolar | Anyone know sth abou or1ksim? | 16:05 |
| stolar | about* | 16:06 |
| stolar | check out my topic at stackoverflow: http://stackoverflow.com/questions/36871006/instruction-of-addition-modulo-255-in-openrisc-simulator-or1ksim | 16:09 |
| stolar | At this moment i have two tasks/points. In the first I need to write instruction of addition modulo 255 to or1ksim and in the second modification toolchain to generate opcode for new instruction from first point | 16:09 |
| olofk | shorne: I put together some pseudo-code for how I think it should work http://a922de54ee64b11d.paste.se/ | 16:10 |
| shorne | olofk: I can run the test case manually, I didnt really have any code yet, but after stekern's points it does match what I was finding in the assembly reverse engineering | 16:10 |
| stolar | + i can pay for solutions | 16:11 |
| olofk | stolar: Homework? :) | 16:11 |
| stolar | yes | 16:12 |
| olofk | haha | 16:12 |
| shorne | yeah, ` if (varargs) out_of_regs =1 ` thats a good idea | 16:12 |
| shorne | olofk: not sure about `if (len > remaining_regs) out_of_regs = 1` | 16:14 |
| shorne | I think if its a big arg like 16 bytes, we put to stack and save ref to register | 16:15 |
| shorne | but if the next arg is an int, it would go to reg directly | 16:15 |
| shorne | but maybe yours is how its implemented in gcc | 16:16 |
| shorne | stolar: is this specifically for or1ksim? or did your professor just say, add to some simulator? | 16:18 |
| shorne | an you chose or1ksim? | 16:18 |
| shorne | If you are using or1ksim then you probably first need to know (1. how to compile, 2. how to run in gdb or sim directly) | 16:21 |
| shorne | which you said you can do | 16:21 |
| shorne | if thats the case you can read the code | 16:21 |
| shorne | I just looked for 2 minutes and can see how to do it, I never looked before (look at recent change logs) | 16:24 |
| shorne | If its for homework you are cheating yourself to ask someone else to do it. | 16:24 |
| olofk | shorne: Yeah, I thought you said something like big args go to stack as well, so I tried something similar to if (is_union() || is_struct()): | 16:26 |
| olofk | crap | 16:26 |
| olofk | if (len > 2*bpw) || (is_union() || is_struct()): | 16:26 |
| shorne | yeah, I just wrote that too | 16:27 |
| shorne | (I was updating your pseudocode) | 16:28 |
| shorne | also, I think `if is_varargs()` needs to go in the arg loop | 16:30 |
| shorne | because the case is starting from varargs we put on stack | 16:31 |
| shorne | `varargs = pass all varargs on stack (even if there would be free registers to pass them in) | 16:31 |
| shorne | - stekern | 16:31 |
| shorne | So a function like printf ("hello %s", val) | 16:32 |
| shorne | r3 = pointer to str | 16:32 |
| shorne | r4 = nothing | 16:32 |
| shorne | val on stack | 16:32 |
| shorne | hmm, but how is that possible to know from which arg we are using varargs :( | 16:34 |
| stolar | shorne: it must be or1ksim | 16:41 |
| shorne | stolar: then the teacher expects you should know enough to figure it out I think. | 16:43 |
| shorne | olofk: I have some assembly here of how its getting hanled : https://gist.github.com/stffrdhrn/6327113d409997466a2ef6edb89c448e#file-openrisc-vargs-gdb-gnu_vector-asm-L290 | 16:44 |
| shorne | stolar: have a look at this change in git https://github.com/openrisc/or1ksim/commit/f75787f390cbd543b8ae49a2670ff338d6e9326a | 16:45 |
| stolar | shorne: yeah, but my teacher is specific person and give hard project for students. You can check it out: https://drive.google.com/folderview?id=0Bxrgd6x3m9NiUkZQXy1aSDl5YUU&usp=sharing and file lista2016l.pdf The majority of projects based on IEEE publications and I and my friends don't have help from teacher, we even don't teach abou it during lectures... | 16:47 |
| shorne | stolar: with the link I provided it should be easy to raed through it and understand | 16:52 |
| stolar | can i name my instruction as i want? e.g. addmod? | 16:57 |
| shorne | yes | 17:02 |
| olofk | shorne: Nice writeup | 17:03 |
| olofk | But do we really care where the varargs start? Aren't all args pushed to the stack for vararg functions? Even the fixed arguments? | 17:05 |
| olofk | ah no...? | 17:05 |
| olofk | I'm looking at m32c-tdep.c now and see 'num_prototyped_args = TYPE_NFIELDS (func_type)' being used near a comment about variadic functions. I wonder if that's the number of real arguments | 17:10 |
| shorne | olofk: yeah, looking at the gcc output it seems not everything is expected to be on the stack | 17:12 |
| stolar | shorne: i look at this github link, at this moment i know that i must edit not one, but few files. There are some really easy file to change e.g. simpl32-defs.h, but I still don't know how to write a test for my new instruction or HOW to write this new instruction, i know that i shulod copy existing instruction (file insnet.c), change name of instruction, but what next? e.g. What does mean SPR_SR_F, cpu_state.sprs[SPR_SR] | 17:12 |
| stolar | shorne: where i can find information what specific variable means? | 17:13 |
| stolar | shorne: can you write this for me for fee? In the next week I will add different instructions so I learn myself something, but nwo i don't have enaugh time to do this. | 17:15 |
| shorne | http://www.cl.cam.ac.uk/research/srg/han/ACS-P35/documents/openrisc_arch.pdf | 17:17 |
| shorne | Default on the names is all in the architecture document | 17:17 |
| olofk | shorne: Yeah, TYPE_NFIELDS seems to do the trick for varargs | 17:18 |
| shorne | I will not write for a fee, you might try to talk to your professor | 17:18 |
| shorne | olofk: cool | 17:18 |
| olofk | For example sh-tdep.c does this `last_reg_arg = TYPE_NFIELDS (func_type) - 2;` | 17:18 |
| olofk | shorne: Also, I found a TYPE_VECTOR macro. Maybe we shouldn't send "largs args" by reference, but instead check if they are vectors instead | 17:20 |
| shorne | RE vectors: I am doing some more checks on that, it looks like maybe they do pass some vector stuff in regs | 17:22 |
| olofk | cool | 17:22 |
| stolar | ok, but i can't find what does mean ' or1k_mstats.byteadd++; ' from the end of existing l_add instruction https://github.com/openrisc/or1ksim/blob/or1k-master/cpu/or32/insnset.c | 17:27 |
| olofk | shorne: I can now push args to the stack starting from the first vararg | 17:34 |
| shorne | olofk: cool, for the issue we had before with `That operation is not available on integers of more than 8 bytes.`: I just looked through this code https://gist.github.com/stffrdhrn/5266b6891c998a4e34cc988d84c0d3d7#file-openrisc-vargs-gdb-gnu_vector-asm-L37 | 17:36 |
| shorne | It seems that what we said about `len > 8 : tread like struct` is right | 17:37 |
| shorne | or bpw*2 | 17:37 |
| olofk | Good to know | 17:37 |
| shorne | olofk: the stuff on the vectors is here: https://gist.github.com/stffrdhrn/5266b6891c998a4e34cc988d84c0d3d7#file-openrisc-vargs-gdb-gnu_vector-asm-L494 | 17:39 |
| shorne | it looks like the values are on the registers, nothing on stack, looking more, will comment on this and upload new doc | 17:40 |
| stolar | shorne: according to (a + b) mod n = [(a mod n) + (b mod n)] mod n and exisiting l_add instruction. I copy existing instruction my my instruction addmod, then i don't make any changes in code that I copy, then I need to write a few code line under existing code in my instruction (at first add two number and then do modulo operation), right? | 17:43 |
| stolar | existin instruction to my instruction* | 17:44 |
| olofk | Time to sleep now. Aaaaalmost there :) | 17:44 |
| stolar | or how to check if my instruction works properly? | 17:50 |
| shorne | stolar: write assembly, and test it in the simulator | 17:57 |
| shorne | olofk: Final writeup on the vector args: https://gist.github.com/stffrdhrn/10ad7ce095c36967107ff851ff62001a#file-openrisc-vargs-gdb-gnu_vector-asm-L534 | 17:58 |
| shorne | We were getting a failure on misaligned access to the return address (maybe we are not providing a good pointer in r3) | 17:58 |
| stolar | shorne: C with __asm__(...) or asm only? | 17:59 |
| shorne | So, we dont need to pass vectors as pointers, but we should pass vector returns as pointers | 17:59 |
| shorne | well, thats given if its in r3 | 18:00 |
| shorne | stolar: in the link I sent, there is also a test case added with some assembly (all asm) you can do like that | 18:00 |
| shorne | olofk: no time to work on now, but hopefully tonight | 18:06 |
| shorne | olofk: but getting close | 18:06 |
| shorne | then its onto the next test failure :) | 18:06 |
| --- Log closed Tue May 17 00:00:10 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!