IRC logs for #openrisc Monday, 2016-05-16

--- Log opened Mon May 16 00:00:08 2016
stekernyeah, educated guessing by writing small tests and looking at the asm is probably the easiest way to figure out what gcc does01:21
stekernI did a lot of that when working on the llvm backend01:22
shornestekern: thats right, I can then compare with gcc and the arch docs to learn it.05:04
shorneolofk: not sure if you saw this but there is a patch for the ABI break/fix
shorneThere is a mail thread about it too.
shorneI am not clear sure what Sebastian means is broken with the varags causing varargs code to need patches to run on openrisc05:08
shorneNice: I found details in an archive here:
shorneFor 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
shorneBut.. that shouldn't break this test case in gnu_vector05:17
shorneunless, there is no way for us to know we are calling a variadic function when preparing the dummy_call.05:18
stekernshorne: yes, but in the end we opted to not change the ABI, since only code with broken assumptions about varargs breaks06:09
shornestekern: yeah, so the issue we are facing with gdb may be this issue if we cant determine the function we are calling in variadic07:36
stekernthat might indeed be tricky07:37
olofkI have a faint memory of some flag that was set for the first vararg. Could remember it wrong, though07:43
shornewhere is 'struct value' and 'TYPE_CODE_STRUCT' defined?07:44
shornehmm, the "struct value *function" arg is never looked at07:47
shornemaybe something in there07:47
olofkFound this in another -tdep file if (TYPE_VARARGS (func_type))07:48
olofkSo it looks like we can detect if we're looking at an varargs function07:52
shornefound TYPE_CODEs in binutils-gdb/gdb/gdbtypes.h07:53
shorneok, cool07:53
olofkStill not sure I understand the difference in the calling conventions though07:58
shorneYeah, 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
stekernolofk: 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
olofkstekern: Ah ok. But does the same rules regarding by-reference/by-value apply as for normal functions?11:10
olofkBecause then we would only have to break the first loop directly if it's a varargs function11:10
stekernolofk: umm, not sure what you are asking11:14
olofkstekern: 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 struct11:16
olofkBut for ints and smaller types the value is put in the register/stack11:16
olofkJust wanted to make sure that there aren't any additional rules regarding varargs, such as even ints are passed by reference11:17
stekernah, no11:17
olofkDidn't think so either, but am treading carefully now :)11:18
stekernthat's wise ;)11:56
olofkhm... I got the impression that shorne got12:09
olofksome changes regarding large args12:09
olofkCan you just run the testcases in gdb manually?12:55
stolarAnyone know sth abou or1ksim?16:05
stolarcheck out my topic at stackoverflow:
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 point16:09
olofkshorne: I put together some pseudo-code for how I think it should work
shorneolofk: 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 engineering16:10
stolar+ i can pay for solutions16:11
olofkstolar: Homework? :)16:11
shorneyeah, ` if (varargs) out_of_regs =1 ` thats a good idea16:12
shorneolofk: not sure about `if (len > remaining_regs) out_of_regs = 1`16:14
shorneI think if its a big arg like 16 bytes, we put to stack and save ref to register16:15
shornebut if the next arg is an int, it would go to reg directly16:15
shornebut maybe yours is how its implemented in gcc16:16
shornestolar: is this specifically for or1ksim? or did your professor just say, add to some simulator?16:18
shornean you chose or1ksim?16:18
shorneIf 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
shornewhich you said you can do16:21
shorneif thats the case you can read the code16:21
shorneI just looked for 2 minutes and can see how to do it,  I never looked before (look at recent change logs)16:24
shorneIf its for homework you are cheating yourself to ask someone else to do it.16:24
olofkshorne: 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
olofkif (len > 2*bpw) || (is_union() || is_struct()):16:26
shorneyeah, I just wrote that too16:27
shorne(I was updating your pseudocode)16:28
shornealso, I think `if is_varargs()` needs to go in the arg loop16:30
shornebecause the case is starting from varargs we put on stack16:31
shorne`varargs = pass all varargs on stack (even if  there would be free registers to pass them in)16:31
shorne - stekern16:31
shorneSo a function like printf ("hello %s", val)16:32
shorner3 = pointer to str16:32
shorner4 = nothing16:32
shorneval on stack16:32
shornehmm, but how is that possible to know from which arg we are using varargs :(16:34
stolarshorne:  it  must be or1ksim16:41
shornestolar: then the teacher expects you should know enough to figure it out I think.16:43
shorneolofk: I have some assembly here of how its getting hanled :
shornestolar: have a look at this change in git
stolarshorne: yeah, but my teacher is specific person and give hard project for students. You can check it out:  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
shornestolar: with the link I provided it should be easy to raed through it and understand16:52
stolarcan i name my instruction as i want? e.g. addmod?16:57
olofkshorne: Nice writeup17:03
olofkBut 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
olofkah no...?17:05
olofkI'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 arguments17:10
shorneolofk: yeah, looking at the gcc output it seems not everything is expected to be on the stack17:12
stolarshorne: 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
stolarshorne: where i can find information what specific variable means?17:13
stolarshorne: 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
shorneDefault on the names is all in the architecture document17:17
olofkshorne: Yeah, TYPE_NFIELDS seems to do the trick for varargs17:18
shorneI will not write for a fee, you might try to talk to your professor17:18
shorneolofk: cool17:18
olofkFor example sh-tdep.c does this `last_reg_arg = TYPE_NFIELDS (func_type) - 2;`17:18
olofkshorne: Also, I found a TYPE_VECTOR macro. Maybe we shouldn't send "largs args" by reference, but instead check if they are vectors instead17:20
shorneRE vectors: I am doing some more checks on that, it looks like maybe they do pass some vector stuff in regs17:22
stolarok, but i can't find what does mean '  or1k_mstats.byteadd++; ' from the end of existing l_add instruction
olofkshorne: I can now push args to the stack starting from the first vararg17:34
shorneolofk: 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
shorneIt seems that what we said about `len > 8 : tread like struct` is right17:37
shorneor bpw*217:37
olofkGood to know17:37
shorneolofk: the stuff on the vectors is here:
shorneit looks like the values are on the registers, nothing on stack, looking more, will comment on this and upload new doc17:40
stolarshorne: 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
stolarexistin instruction to my instruction*17:44
olofkTime to sleep now. Aaaaalmost there :)17:44
stolaror how to check if my instruction works properly?17:50
shornestolar: write assembly, and test it in the simulator17:57
shorneolofk: Final writeup on the vector args:
shorneWe were getting a failure on misaligned access to the return address (maybe we are not providing a good pointer in r3)17:58
stolarshorne: C with __asm__(...) or asm only?17:59
shorneSo, we dont need to pass vectors as pointers, but we should pass vector returns as pointers17:59
shornewell, thats given if its in r318:00
shornestolar: in the link I sent, there is also a test case added with some assembly (all asm) you can do like that18:00
shorneolofk: no time to work on now, but hopefully tonight18:06
shorneolofk: but getting close18:06
shornethen its onto the next test failure :)18:06
--- Log closed Tue May 17 00:00:10 2016

Generated by 2.15.2 by Marius Gedminas - find it at!