| --- Log opened Sun Jul 14 00:00:26 2013 | ||
| stekern | poke53281: it'll take a looong time, depending on your machine, but count on 1-2 days | 02:39 |
|---|---|---|
| stekern | jeremy did some additional scripts to run several tests (with several or1ksim) in parallell to speed things up, but I've never used them | 02:40 |
| stekern | blueCmd: ok, thanks for confirming that | 02:40 |
| stekern | olofk: agree, we (I) should put instructions on the wiki for it | 02:46 |
| poke53281 | I have reckognized it. After the first 20000 checks I got an error: WARNING: telnet: got unexpected EOF from telnet. | 02:46 |
| poke53281 | or1ksim crashed | 02:47 |
| poke53281 | Is there a way to exactly restart at a very specific point. I have only found solutions with wildcards. | 02:48 |
| stekern | unfortunately not that I'm aware of | 02:48 |
| poke53281 | Did you see the error before? | 02:48 |
| stekern | yes, when I had set a password to the root account (so the testscript couldn't logon) | 02:49 |
| stekern | but, or1ksim can crash, yes | 02:50 |
| poke53281 | I didn't | 02:50 |
| stekern | yeah, if 20000 tests pass it probably have succeeded to log in at some point | 02:50 |
| poke53281 | I take or1ksim from github.com/openrisc. Is this correct or outdated? | 02:51 |
| poke53281 | Ok, if it stops again at the same point I know where to look. | 02:51 |
| stekern | actually I think jeremy's additional scripts might restart from the right place when or1ksim crashes | 02:51 |
| stekern | http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fgnu-stable%2Fdoc%2Ftesting.txt | 02:51 |
| stekern | what does the .log file says | 02:52 |
| stekern | the one from github is the one I'm using as well, it should be the most up-to-date | 02:52 |
| poke53281 | no failures from 19547 passes | 02:53 |
| stekern | ah, but I meant where the test fails | 02:54 |
| poke53281 | otherwise more or less the same. No route to host. | 02:54 |
| stekern | aha, ok | 02:54 |
| poke53281 | or1ksim simply crashes for some reason. | 02:55 |
| stekern | but yeah, if or1ksim has crashed, the reason is pretty clear | 02:55 |
| stekern | I have more subtles problems, a lot more c++ tests are failing now.... | 02:55 |
| poke53281 | let's see when I am there. If it crashes again ( but at another point) I can start some c++ tests | 02:57 |
| poke53281 | Or I can start directly some you mentioned. Maybe you can pastie some tests which are failing. | 02:57 |
| poke53281 | Then I can try them directly. | 02:58 |
| stekern | if you run make check-gcc-c++ it'll start failing pretty directly | 02:58 |
| poke53281 | Did you update your libstdc++ in your sysroot. You said something about libgcc. libstdc++ is as important. | 02:58 |
| stekern | yes, I did | 03:01 |
| stekern | looks like some lib is doing unaligned accesses somewhere and then segfaults | 03:04 |
| poke53281 | Ahh, this explains it. | 03:05 |
| poke53281 | So far there is no solution for the kernel. | 03:05 |
| poke53281 | If you do a non-aligned access Linux crashes. So we need a handler. Or remove the limit from or1ksim. :) | 03:06 |
| stekern | yeah, I know | 03:07 |
| stekern | there actually is a handler in Linux, but I think it's broken | 03:08 |
| stekern | but that's not the problem. the unaligned access is probably just the result of the problem | 03:08 |
| poke53281 | could be | 03:09 |
| stekern | I would be surprised if any gcc lib does unaligned accesses deliberately | 03:09 |
| poke53281 | well, I will start as soon as possible. But I don't want to stop the run | 03:09 |
| poke53281 | not that I know. unaligned memcpy or memset maybe | 03:10 |
| stekern | in contrast to the vararg abi, there are other 'big' archs out there that doesn't support unaligned accesses | 03:11 |
| poke53281 | doesn't support or don't handle it. | 03:12 |
| poke53281 | ARM doesn't support but handles it in the kernel. | 03:12 |
| stekern | and on the ones that do support it, there's usually a performance penalty involved, so people try to avoid it | 03:12 |
| poke53281 | Yes | 03:13 |
| stekern | umm, I thought at least some ARM flavours have (hw) unaligned access support? | 03:13 |
| stekern | why is LD_DEBUG so annoying in uclibc? | 03:14 |
| poke53281 | I think there is a flag. I can take a look in the ARM_ARM.pdf (Architecture Reference Manual) | 03:14 |
| stekern | you need to build in debugging support to ld.so for LD_DEBUG to have any effect, but if you do it prints a lot of debug messages when LD_DEBUG isn't used | 03:15 |
| poke53281 | I know this problem very well. Do you remember this missing symlink? | 03:17 |
| stekern | symlink? | 03:18 |
| poke53281 | The first time when I compiled the support for shared libraries. I got the error message "not found" which was not very helpful. | 03:19 |
| stekern | ah, yes | 03:20 |
| stekern | that should be fixed now btw, so you don't need the symlink | 03:20 |
| poke53281 | Not sure. It is still in my script | 03:21 |
| poke53281 | So I don't know | 03:21 |
| poke53281 | The arm processor has to different alignment models which can be switched with the bit SCTLR.U | 03:22 |
| poke53281 | The second one support unaligned access. The first one is for compatibility of old code and is deprecated | 03:22 |
| poke53281 | I 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 |
| poke53281 | But I don't like my solution and I don't understand it completely. | 03:26 |
| poke53281 | Expecially the behavior between stack_pointer_rtx and arg_pointer_rtx | 03:27 |
| poke53281 | Both work on the stack | 03:28 |
| stekern | where are those used? | 03:29 |
| poke53281 | stack_pointer_rtx is more or less directly r1 | 03:29 |
| poke53281 | emit_frame_insn (gen_add2_insn (stack_pointer_rtx, GEN_INT (-frame_info.gpr_frame)) | 03:30 |
| poke53281 | with this command I can add an instruction to change r1 by one factor. In this case frame_info.gpr_frame | 03:30 |
| poke53281 | It is used multiple times in or1k.c | 03:31 |
| poke53281 | On 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 |
| poke53281 | If I add an instruction like emit_frame_insn (gen_add2_insn (arg_pointer_rtx, GEN_INT (-frame_info.gpr_frame)) | 03:32 |
| poke53281 | I get an internal compiler error. | 03:32 |
| poke53281 | Probably because there is no register for it. I don't know. | 03:33 |
| poke53281 | So far understood? | 03:33 |
| poke53281 | If 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 |
| poke53281 | So I am little bit puzzled and don't trust my solution. | 03:37 |
| stekern | ah, but I meant, where are those used in your code | 03:46 |
| poke53281 | I have to move the pointer of the value of pretend_args_size that it thinks that the args are beginning there. | 03:47 |
| stekern | hmm, but I don't think you have to modify the arg_pointer_rtx | 03:50 |
| poke53281 | I don't do it | 03:50 |
| poke53281 | http://pastie.org/8139042 | 03:51 |
| poke53281 | the arg_pointer_rtx is mainly shown in line 2c. | 03:53 |
| poke53281 | sorry, offset 2c | 03:53 |
| stekern | I'm not sure I understand the problem though ;) | 03:54 |
| poke53281 | and this is the same as the gpr_frame | 03:54 |
| poke53281 | for offset 0 and c I use the same code. But they have different behavior on offset 2c | 03:54 |
| poke53281 | Understood :) | 03:55 |
| stekern | when do they have different behaviour on offset 2c? | 03:56 |
| poke53281 | Well, I will run the testsuite and compare with other architectures. Then I will hopefully understand it. | 03:56 |
| stekern | you can take a look at m32r/m32r.c, that seems to do what you want to achieve | 03:57 |
| poke53281 | or1k_expand_prologue (void) | 03:58 |
| poke53281 | { | 03:58 |
| poke53281 | emit_frame_insn (gen_add2_insn (stack_pointer_rtx, | 03:58 |
| poke53281 | GEN_INT (-frame_info.gpr_frame))); | 03:58 |
| poke53281 | } | 03:58 |
| poke53281 | or1k_expand_prologue (void) | 03:58 |
| poke53281 | { | 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 |
| poke53281 | } | 03:58 |
| poke53281 | Both code is not equivalent (if you assume that gpr_frame can be divided by 2) | 03:58 |
| stekern | I 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 |
| stekern | but you say it doesn't? | 04:00 |
| poke53281 | Both produce asm. But they seem to have different effect on the arg_pointer_rtx | 04:00 |
| poke53281 | Well, I can simpy debug :) | 04:01 |
| poke53281 | And directly look on the arg_pointer_rtx structure | 04:01 |
| stekern | but the argpointer is just an offset relative to r1, no? | 04:02 |
| poke53281 | Yes, should be. But of course it depends on my prologue. And there I am moving r1. | 04:03 |
| stekern | I don't think emitting stackpointer modifications have any effect on that | 04:03 |
| stekern | i.e. r1 modifying instructions | 04:04 |
| poke53281 | So 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 |
| poke53281 | But at the moment is seems neither/nor | 04:04 |
| stekern | yeah, but I don't think the argpointer cares what you do with r1 | 04:04 |
| poke53281 | It depends if this is a relative or absolute pointer. On the stack it should be always a relative pointer | 04:05 |
| poke53281 | m32r.c seems to be very similar. | 04:07 |
| poke53281 | I will find a good solution. I am very close to it. | 04:08 |
| stekern | but isn't your comments in the asm you pasted wrong? | 04:10 |
| stekern | or am I just misreading them | 04:10 |
| stekern | isn't the instructions on offset 0x0 and 0x58 the ones that you have added? | 04:11 |
| poke53281 | Could be, but this code works :) | 04:11 |
| poke53281 | I have added both in the prologue and epilogue. The gpr-frame is of course bigger because I have save 20 additional bytes. | 04:12 |
| poke53281 | In the old code this would be only 4 and not 24 | 04:12 |
| poke53281 | offset c - 20 and offset 4c I added | 04:14 |
| poke53281 | and the gpr_frame is bigger. | 04:14 |
| stekern | ah, now I see | 04:14 |
| stekern | but why is the gpr_frame bigger? | 04:15 |
| poke53281 | I 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 |
| stekern | yes, but that's what you do in 0xc | 04:16 |
| stekern | right? | 04:16 |
| poke53281 | gpr is the abbreviation for general purpose register? | 04:16 |
| stekern | yes | 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 |
| stekern | yes, but that's what you do in 0xc | 04:18 |
| poke53281 | Yes | 04:18 |
| stekern | why is another 20 bytes added at 0x0 | 04:18 |
| stekern | ? | 04:18 |
| poke53281 | one is for the real space I need. One is to fool all pointers. The 20 bytes are never accessed. | 04:19 |
| stekern | because the function only uses 4 bytes to store r1 | 04:19 |
| poke53281 | every access to the stack adds this 20 bytes again | 04:19 |
| poke53281 | 4+20 | 04:19 |
| stekern | umm, that doesn't sound right | 04:19 |
| poke53281 | As 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 |
| poke53281 | m32r.c seems to have a similar solution on the first glance. But I have to check it | 04:22 |
| stekern | yeah, I believe it generates code that works, but seems a bit odd to always have to "waste" stack space like that | 04:22 |
| poke53281 | Yes, you are right. I don't the space but of course if I execute another function this space is wasted | 04:23 |
| poke53281 | .... don't use the space .... | 04:23 |
| stekern | if you look at line 1693 in m32r.c, there the pretend_size is subtracted from the total frame size | 04:26 |
| poke53281 | I have seen it | 04:26 |
| poke53281 | and they add the space for pretend_size directly in the beginning of the prologue. I do it at the end. | 04:27 |
| stekern | yeah, but I think you should add it in the beginning, that's what confused me about the comments, because I thought you did that | 04:28 |
| stekern | because, think about how a normal function which pass arguments on the stack works, the caller is the one that allocates the stack space | 04:29 |
| stekern | so that's what you have to emulate | 04:29 |
| poke53281 | I 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 |
| poke53281 | the caller allocates only space for the parameters as far as I have seen. | 04:30 |
| stekern | yeah, that's what I meant with "the caller is the one that allocates the stack space | 04:31 |
| stekern | " | 04:31 |
| poke53281 | Anyway 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 |
| poke53281 | I have never worked with gcc-code before. | 04:35 |
| poke53281 | source code | 04:35 |
| stekern | yeah, your doing very well I'd say! ;) | 04:36 |
| stekern | I'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 neither | 04:36 |
| stekern | meanwhile, I've found what's unaligned, it seems to be __gxx_personality_v0 | 04:39 |
| stekern | whatever that is... | 04:39 |
| poke53281 | Have seen it but forgotten | 04:39 |
| poke53281 | the torture test is done 23198 of expected passes | 04:40 |
| stekern | sounds good | 04:41 |
| poke53281 | I am starting check-gcc-c++ | 04:41 |
| poke53281 | I have to start the other 50000 C-tests later | 04:41 |
| poke53281 | FAIL: g++ .dg/bprob/g++-bprob-1.C execution, -g -fprofile-arcs | 04:42 |
| stekern | yeah, that's exactly the one I'm looking at | 04:43 |
| stekern | do you have a segfault in the .log too? | 04:43 |
| poke53281 | Yes | 04:44 |
| stekern | ok, that's at least good to know, it's nothing in what I merged from upstream then | 04:45 |
| poke53281 | No, but It already implements the change of init/fin | 04:45 |
| stekern | yeah, but it's not related to that | 04:46 |
| stekern | I *highly* doubt that it would be related to that at least ;) | 04:46 |
| poke53281 | Yes, I don't believe so. | 04:46 |
| poke53281 | Well, you will find out. Otherwise I will do. | 04:47 |
| stekern | this happens when ld.so tries to resolve __gxx_personality_v0 | 04:47 |
| poke53281 | So it's an error in the linker? | 04:51 |
| stekern | no, it's just that's unaligned I think | 04:52 |
| stekern | why it's unaligned, that's what I'm trying to find out now | 04:52 |
| stekern | could of course be in ld.so, calculating the address wrong | 04:52 |
| poke53281 | got it. Did it like in m32r and now it works for my test cases | 05:08 |
| stekern | oh, it finds an R_OR1K_32 in .eh_frame | 05:08 |
| stekern | poke53281: great! | 05:11 |
| stekern | as usual, we're not the first to experience problems like this: http://sourceware.org/ml/libc-ports/2011-12/msg00017.html | 05:57 |
| stekern | and the bug referenced in that patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 | 05:58 |
| stekern | so looks like we have to fix unaligned relocations in uclibc | 05:59 |
| poke53281 | so an error in uclibc | 06:02 |
| poke53281 | Linux boots, Busybox crashes. Something is still missing | 06:06 |
| poke53281 | does it crash because the kernel cannot handle unaligned access? Then I would correct this instead of uclibc. | 06:07 |
| stekern | busybox? you mean one you've built? | 06:26 |
| stekern | ah, the busybox comment was unrelated to the uclibc comment | 06:29 |
| poke53281 | yes | 06:32 |
| stekern | agree, linux should be fixed, either by properly implementing "emulated" unaligned accesses, or scream violently when they happen | 06:35 |
| stekern | I think it's still worthwhile to fix it in uclibc | 06:37 |
| stekern | ah, actually, the broken unaligned handler I was thinking about have been removed completely | 06:53 |
| stekern | so, it just sends a sigsegv to the process if it's in userspace, and die() if it's a kernel access | 06:53 |
| stekern | ok, blueCmd have done this in eglibc I see: https://github.com/blueCommand/or1k-eglibc/commit/8a2e901a484fba245ffb8f346cda93827236e630 | 06:57 |
| stekern | the same thing as was done in the patch I linked | 06:58 |
| stekern | hmm, adding that doesn't do it, it happens earlier than that | 07:40 |
| stekern | ah, when debugging is turned on, it reads the old value | 07:46 |
| poke53281 | Hmm, strange. | 08:14 |
| poke53281 | busybox, uclibc, ncurses, nano, and especially DirectFB seems to work now. | 08:16 |
| poke53281 | This is enough for today. Have to sleep | 08:16 |
| stekern | good night | 08:35 |
| stekern | unaligned R_OR1K_32 seems to work too now | 08:39 |
| stekern | http://pastie.org/8140164 | 15:56 |
| stekern | still 86 failures, which is a tad more than last I seriously ran the tests, but not insane anymore | 15:56 |
| poke53281 | Great 86 fails are not bad. And it was just this one patch? | 16:30 |
| stekern | yes, only this pathc | 16:42 |
| stekern | *patch | 16:42 |
| stekern | there are a couple of segfaults and unaligned accesses, which might be low hanging fruit | 16:42 |
| stekern | and then a couple of fails because there is no .gcda file | 16:42 |
| stekern | the rest looks more subtle | 16:43 |
| stekern | ...a couple are failed diagnostics by the look of it, but I don't see how that can be target specific | 16:43 |
| stekern | i.e. error messages not emitted when they should | 16:44 |
| stekern | ah, the missing gcda files are because the ftp default root is / but the telnet root is /root/ | 17:24 |
| stekern | so it tries to get them from /, but they are in /root/ | 17:24 |
| stekern | I'll cheat a bit and put a couple of symlinks to the gcda files | 17:26 |
| poke53281 | I have the same configuration | 17:32 |
| poke53281 | gcc runs without native patches. 80% of directfb works. SDL seems to work. X still crashes | 18:50 |
| stekern | maybe the remaining 20% of directfb is something else | 18:54 |
| stekern | and if we're lucky, X is because of those 20% too ;) | 18:54 |
| poke53281 | I 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 |
| poke53281 | And these are the most advanced demos like 3D. | 18:57 |
| stekern | ah, ok, nice ;) | 18:57 |
| poke53281 | 20 minutes ago they stopped with a segmentation fault. | 18:58 |
| stekern | heh, ok... that's not so nice | 18:58 |
| poke53281 | maybe they tried to use opengl I didn't compile Mesa at that point. Who knows. | 18:59 |
| poke53281 | You can try yourself if you want. Everything is online :) | 19:00 |
| poke53281 | mount /dev/sda /mnt | 19:00 |
| poke53281 | cd /mnt | 19:00 |
| poke53281 | ./startchroot | 19:00 |
| poke53281 | df_texture | 19:00 |
| poke53281 | switch to framebuffer and wait | 19:00 |
| poke53281 | nice is also df_neo, df_matrix, df_knuckles, df_dok | 19:02 |
| stekern | very cool, I've got to test this on real hw someday too | 19:07 |
| poke53281 | keyboard input does not work for directfb. But I know more or less why | 19:08 |
| poke53281 | with real hardware you mean FPGAs | 19:22 |
| stekern | yup | 19:24 |
| poke53281 | is there some way to install a native gdb? | 20:06 |
| poke53281 | Ok, there is a wiki. But only for o32 | 20:08 |
| poke53281 | error: "*** Gdb does not support native target or1k-unknown-linux-gnu" | 20:21 |
| poke53281 | with the or1k-elf seems to work, but not or1k-linux | 20:21 |
| --- Log closed Mon Jul 15 00:00:27 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!