IRC logs for #openrisc Sunday, 2013-07-14

--- Log opened Sun Jul 14 00:00:26 2013
stekernpoke53281: it'll take a looong time, depending on your machine, but count on 1-2 days02:39
stekernjeremy did some additional scripts to run several tests (with several or1ksim) in parallell to speed things up, but I've never used them02:40
stekernblueCmd: ok, thanks for confirming that02:40
stekernolofk: agree, we (I) should put instructions on the wiki for it02:46
poke53281I have reckognized it. After the first 20000 checks I got an error: WARNING: telnet: got unexpected EOF from telnet.02:46
poke53281or1ksim crashed02:47
poke53281Is there a way to exactly restart at a very specific point. I have only found solutions with wildcards.02:48
stekernunfortunately not that I'm aware of02:48
poke53281Did you see the error before?02:48
stekernyes, when I had set a password to the root account (so the testscript couldn't logon)02:49
stekernbut, or1ksim can crash, yes02:50
poke53281I didn't02:50
stekernyeah, if 20000 tests pass it probably have succeeded to log in at some point02:50
poke53281I take or1ksim from Is this correct or outdated?02:51
poke53281Ok, if it stops again at the same point I know where to look.02:51
stekernactually I think jeremy's additional scripts might restart from the right place when or1ksim crashes02:51
stekernwhat does the .log file says02:52
stekernthe one from github is the one I'm using as well, it should be the most up-to-date02:52
poke53281no failures from 19547 passes02:53
stekernah, but I meant where the test fails02:54
poke53281otherwise more or less the same. No route to host.02:54
stekernaha, ok02:54
poke53281or1ksim simply crashes for some reason.02:55
stekernbut yeah, if or1ksim has crashed, the reason is pretty clear02:55
stekernI have more subtles problems, a lot more c++ tests are failing now....02:55
poke53281let's see when I am there. If it crashes again ( but at another point) I can start some c++ tests02:57
poke53281Or I can start directly some you mentioned. Maybe you can pastie some tests which are failing.02:57
poke53281Then I can try them directly.02:58
stekernif you run make check-gcc-c++ it'll start failing pretty directly02:58
poke53281Did you update your libstdc++ in your sysroot. You said something about libgcc. libstdc++ is as important.02:58
stekernyes, I did03:01
stekernlooks like some lib is doing unaligned accesses somewhere and then segfaults03:04
poke53281Ahh, this explains it.03:05
poke53281So far there is no solution for the kernel.03:05
poke53281If you do a non-aligned access Linux crashes. So we need a handler. Or remove the limit from or1ksim. :)03:06
stekernyeah, I know03:07
stekernthere actually is a handler in Linux, but I think it's broken03:08
stekernbut that's not the problem. the unaligned access is probably just the result of the problem03:08
poke53281could be03:09
stekernI would be surprised if any gcc lib does unaligned accesses deliberately03:09
poke53281well, I will start as soon as possible. But I don't want to stop the run03:09
poke53281not that I know. unaligned memcpy or memset maybe03:10
stekernin contrast to the vararg abi, there are other 'big' archs out there that doesn't support unaligned accesses03:11
poke53281doesn't support or don't handle it.03:12
poke53281ARM doesn't support but handles it in the kernel.03:12
stekernand on the ones that do support it, there's usually a performance penalty involved, so people try to avoid it03:12
stekernumm, I thought at least some ARM flavours have (hw) unaligned access support?03:13
stekernwhy is LD_DEBUG so annoying in uclibc?03:14
poke53281I think there is a flag. I can take a look in the ARM_ARM.pdf (Architecture Reference Manual)03:14
stekernyou need to build in debugging support to for LD_DEBUG to have any effect, but if you do it prints a lot of debug messages when LD_DEBUG isn't used03:15
poke53281I know this problem very well. Do you remember this missing symlink?03:17
poke53281The first time when I compiled the support for shared libraries. I got the error message "not found" which was not very helpful.03:19
stekernah, yes03:20
stekernthat should be fixed now btw, so you don't need the symlink03:20
poke53281Not sure. It is still in my script03:21
poke53281So I don't know03:21
poke53281The arm processor has to different alignment models which can be switched with the bit SCTLR.U03:22
poke53281The second one support unaligned access. The first one is for compatibility of old code and is deprecated03:22
poke53281I have a (more or less) good message. I have solved the varargs problem. At least I think so. My 5 testcases work as expected.03:26
poke53281But I don't like my solution and I don't understand it completely.03:26
poke53281Expecially the behavior between stack_pointer_rtx and arg_pointer_rtx03:27
poke53281Both work on the stack03:28
stekernwhere are those used?03:29
poke53281stack_pointer_rtx is more or less directly r103:29
poke53281emit_frame_insn (gen_add2_insn (stack_pointer_rtx, GEN_INT (-frame_info.gpr_frame))03:30
poke53281with this command I can add an instruction to change r1 by one factor. In this case frame_info.gpr_frame03:30
poke53281It is used multiple times in or1k.c03:31
poke53281On our architecture arg_pointer_rtx is not in a register. It is more like a virtual pointer which is in some way dependent on on the stack_pointer.03:32
poke53281If I add an instruction like emit_frame_insn (gen_add2_insn (arg_pointer_rtx, GEN_INT (-frame_info.gpr_frame))03:32
poke53281I get an internal compiler error.03:32
poke53281Probably because there is no register for it. I don't know.03:33
poke53281So far understood?03:33
poke53281If I add such a function (with stack_pointer_rtx) in the function expand_prologue it corrects automatically the arg_pointer_rtx. The problem is if I put this function a second time somewhere in the function, the arg_pointer_rtx is not updated. This behavior I am using at the moment to solve the problem.03:37
poke53281So I am little bit puzzled and don't trust my solution.03:37
stekernah, but I meant, where are those used in your code03:46
poke53281I have to move the pointer of the value of pretend_args_size that it thinks that the args are beginning there.03:47
stekernhmm, but I don't think you have to modify the arg_pointer_rtx03:50
poke53281I don't do it03:50
poke53281the arg_pointer_rtx is mainly shown in line 2c.03:53
poke53281sorry, offset 2c03:53
stekernI'm not sure I understand the problem though ;)03:54
poke53281and this is the same as the gpr_frame03:54
poke53281for offset 0 and c I use the same code. But they have different behavior on offset 2c03:54
poke53281Understood :)03:55
stekernwhen do they have different behaviour on offset 2c?03:56
poke53281Well, I will run the testsuite and compare with other architectures. Then I will hopefully understand it.03:56
stekernyou can take a look at m32r/m32r.c, that seems to do what you want to achieve03:57
poke53281or1k_expand_prologue (void)03:58
poke53281    emit_frame_insn (gen_add2_insn (stack_pointer_rtx,03:58
poke53281    GEN_INT (-frame_info.gpr_frame)));03:58
poke53281or1k_expand_prologue (void)03:58
poke53281    emit_frame_insn (gen_add2_insn (stack_pointer_rtx,03:58
poke53281    GEN_INT (-frame_info.gpr_frame/2)));03:58
poke53281    emit_frame_insn (gen_add2_insn (stack_pointer_rtx,03:58
poke53281    GEN_INT (-frame_info.gpr_frame/2)));03:58
poke53281Both code is not equivalent (if you assume that gpr_frame can be divided by 2)03:58
stekernI would assume that that would generate asm that's the same as if you would do: emit_frame_insn (gen_add2_insn (stack_pointer_rtx, GEN_INT (-frame_info.gpr_frame)));04:00
stekernbut you say it doesn't?04:00
poke53281Both produce asm. But they seem to have different effect on the arg_pointer_rtx04:00
poke53281Well, I can simpy debug :)04:01
poke53281And directly look on the arg_pointer_rtx structure04:01
stekernbut the argpointer is just an offset relative to r1, no?04:02
poke53281Yes, should be. But of course it depends on my prologue. And there I am moving r1.04:03
stekernI don't think emitting stackpointer modifications have any effect on that04:03
stekerni.e. r1 modifying instructions04:04
poke53281So if I am moving r1, the offset should change as well. Or it is given as fixed number, which would be Ok too.04:04
poke53281But at the moment is seems neither/nor04:04
stekernyeah, but I don't think the argpointer cares what you do with r104:04
poke53281It depends if this is a relative or absolute pointer. On the stack it should be always a relative pointer04:05
poke53281m32r.c seems to be very similar.04:07
poke53281I will find a good solution. I am very close to it.04:08
stekernbut isn't your comments in the asm you pasted wrong?04:10
stekernor am I just misreading them04:10
stekernisn't the instructions on offset 0x0 and 0x58 the ones that you have added?04:11
poke53281Could be, but this code works :)04:11
poke53281I have added both in the prologue and epilogue. The gpr-frame is of course bigger because I have save 20 additional bytes.04:12
poke53281In the old code this would be only 4 and not 2404:12
poke53281offset c - 20 and offset 4c I added04:14
poke53281and the gpr_frame is bigger.04:14
stekernah, now I see04:14
stekernbut why is the gpr_frame bigger?04:15
poke53281I have to save the args from the registers into the stack. Good, I am not sure if I can call this still the gpr_frame.04:15
stekernyes, but that's what you do in 0xc04:16
poke53281gpr is the abbreviation for general purpose register?04:16
poke53281"pretend_args_size. The value that you store here will serve as additional offset for setting up the stack frame. "04:17
stekernyes, but that's what you do in 0xc04:18
stekernwhy is another 20 bytes added at 0x004:18
poke53281one is for the real space I need. One is to fool all pointers. The 20 bytes are never accessed.04:19
stekernbecause the function only uses 4 bytes to store r104:19
poke53281every access to the stack adds this 20 bytes again04:19
stekernumm, that doesn't sound right04:19
poke53281As I said I am a little bit confused as well. But it works for my test cases but I don't trust the solution.04:21
poke53281m32r.c seems to have a similar solution on the first glance. But I have to check it04:22
stekernyeah, I believe it generates code that works, but seems a bit odd to always have to "waste" stack space like that04:22
poke53281Yes, you are right. I don't the space but of course if I execute another function this space is wasted04:23
poke53281.... don't use the space ....04:23
stekernif you look at line 1693 in m32r.c, there the pretend_size is subtracted from the total frame size04:26
poke53281I have seen it04:26
poke53281and they add the space for pretend_size directly in the beginning of the prologue. I do it at the end.04:27
stekernyeah, but I think you should add it in the beginning, that's what confused me about the comments, because I thought you did that04:28
stekernbecause, think about how a normal function which pass arguments on the stack works, the caller is the one that allocates the stack space04:29
stekernso that's what you have to emulate04:29
poke53281I did it this way in the beginning. But then my argument_pointer changed as well. And now we are at the beginning of my story;)04:29
poke53281the caller allocates only space for the parameters as far as I have seen.04:30
stekernyeah, that's what I meant with "the caller is the one that allocates the stack space04:31
poke53281Anyway I am working for 6 hours on a source code which interfaces a base of 7.3 million lines of code. I didn't expect at the beginning to be that far.04:34
poke53281I have never worked with gcc-code before.04:35
poke53281source code04:35
stekernyeah, your doing very well I'd say! ;)04:36
stekernI'm no expert neither, I have only dabbled with the gcc code, I know the llvm code a lot better, but no expert on that neither04:36
stekernmeanwhile, I've found what's unaligned, it seems to be __gxx_personality_v004:39
stekernwhatever that is...04:39
poke53281Have seen it but forgotten04:39
poke53281the torture test is done 23198 of expected passes04:40
stekernsounds good04:41
poke53281I am starting check-gcc-c++04:41
poke53281I have to start the other 50000 C-tests later04:41
poke53281FAIL: g++ .dg/bprob/g++-bprob-1.C execution,       -g   -fprofile-arcs04:42
stekernyeah, that's exactly the one I'm looking at04:43
stekerndo you have a segfault in the .log too?04:43
stekernok, that's at least good to know, it's nothing in what I merged from upstream then04:45
poke53281No, but It already implements the change of  init/fin04:45
stekernyeah, but it's not related to that04:46
stekernI *highly* doubt that it would be related to that at least ;)04:46
poke53281Yes, I don't believe so.04:46
poke53281Well, you will find out. Otherwise I will do.04:47
stekernthis happens when tries to resolve __gxx_personality_v004:47
poke53281So it's an error in the linker?04:51
stekernno, it's just that's unaligned I think04:52
stekernwhy it's unaligned, that's what I'm trying to find out now04:52
stekerncould of course be in, calculating the address wrong04:52
poke53281got it. Did it like in m32r and now it works for my test cases05:08
stekernoh, it finds an R_OR1K_32 in .eh_frame05:08
stekernpoke53281: great!05:11
stekernas usual, we're not the first to experience problems like this:
stekernand the bug referenced in that patch:
stekernso looks like we have to fix unaligned relocations in uclibc05:59
poke53281so an error in uclibc06:02
poke53281Linux boots, Busybox crashes. Something is still missing06:06
poke53281does it crash because the kernel cannot handle unaligned access? Then I would correct this instead of uclibc.06:07
stekernbusybox? you mean one you've built?06:26
stekernah, the busybox comment was unrelated to the uclibc comment06:29
stekernagree, linux should be fixed, either by properly implementing "emulated" unaligned accesses, or scream violently when they happen06:35
stekernI think it's still worthwhile to fix it in uclibc06:37
stekernah, actually, the broken unaligned handler I was thinking about have been removed completely06:53
stekernso, it just sends a sigsegv to the process if it's in userspace, and die() if it's a kernel access06:53
stekernok, blueCmd have done this in eglibc I see:
stekernthe same thing as was done in the patch I linked06:58
stekernhmm, adding that doesn't do it, it happens earlier than that07:40
stekernah, when debugging is turned on, it reads the old value07:46
poke53281Hmm, strange.08:14
poke53281busybox, uclibc, ncurses, nano, and especially DirectFB seems to work now.08:16
poke53281This is enough for today. Have to sleep08:16
stekerngood night08:35
stekernunaligned R_OR1K_32 seems to work too now08:39
stekernstill 86 failures, which is a tad more than last I seriously ran the tests, but not insane anymore15:56
poke53281Great 86 fails are not bad. And it was just this one patch?16:30
stekernyes, only this pathc16:42
stekernthere are a couple of segfaults and unaligned accesses, which might be low hanging fruit16:42
stekernand then a couple of fails because there is no .gcda file16:42
stekernthe rest looks more subtle16:43
stekern...a couple are failed diagnostics by the look of it, but I don't see how that can be target specific16:43
stekerni.e. error messages not emitted when they should16:44
stekernah, the missing gcda files are because the ftp default root is / but the telnet root is /root/17:24
stekernso it tries to get them from /, but they are in /root/17:24
stekernI'll cheat a bit and put a couple of symlinks to the gcda files17:26
poke53281I have the same configuration17:32
poke53281gcc runs without native patches. 80% of directfb works. SDL seems to work. X still crashes18:50
stekernmaybe the remaining 20% of directfb is something else18:54
stekernand if we're lucky, X is because of those 20% too ;)18:54
poke53281I have to correct myself. For some reason these 20% of DirectFB does no longer stop with a segmentation fault but with an unsupported mode failure. This is Ok.18:57
poke53281And these are the most advanced demos like 3D.18:57
stekernah, ok, nice ;)18:57
poke5328120 minutes ago they stopped with a segmentation fault.18:58
stekernheh, ok... that's not so nice18:58
poke53281maybe they tried to use opengl I didn't compile Mesa at that point. Who knows.18:59
poke53281You can try yourself if you want. Everything is online :)19:00
poke53281mount /dev/sda /mnt19:00
poke53281cd /mnt19:00
poke53281switch to framebuffer and wait19:00
poke53281nice is also df_neo, df_matrix, df_knuckles, df_dok19:02
stekernvery cool, I've got to test this on real hw someday too19:07
poke53281keyboard input does not work for directfb. But I know more or less why19:08
poke53281with real hardware you mean FPGAs19:22
poke53281is there some way to install a native gdb?20:06
poke53281Ok, there is a wiki. But only for o3220:08
poke53281error: "*** Gdb does not support native target or1k-unknown-linux-gnu"20:21
poke53281with the or1k-elf seems to work, but not or1k-linux20:21
--- Log closed Mon Jul 15 00:00:27 2013

Generated by 2.15.2 by Marius Gedminas - find it at!