--- Log opened Wed Sep 24 00:00:07 2014 | ||
poke53282 | to set up dejagnu took only one hour. A improvement by a factor of ten in comparison to last year | 01:22 |
---|---|---|
poke53282 | http://pastie.org/9589561 | 02:36 |
poke53282 | http://pastie.org/9589567 | 02:41 |
poke53282 | The current errors | 02:41 |
poke53282 | stekern: "cat /proc/cpuinfo" . Does it work? | 03:37 |
stekern | poke53282: yes: http://pastie.org/9589780 | 05:29 |
poke53282 | is smp active? | 05:45 |
poke53282 | I haven't compiled it in. | 05:46 |
stekern | poke53282: it works with it compiled in and not | 06:25 |
poke53282 | Ok, thanks | 06:28 |
_franck__ | cool, I'll be at the orconf. I have a FAE meeting the days before the orconf weekend. | 08:50 |
_franck__ | I'll be in Augsbourg, close to Munich | 08:52 |
stekern | Fatty Acid Ester meeting? | 09:30 |
_franck__ | almost :) | 09:43 |
stekern | either way, good news! ;) | 09:57 |
sb0 | what's that meeting? | 10:54 |
olofk | _franck__: Good news. I saw that you registered. I was afraid you would be buried under your house by now | 12:21 |
olofk | poke53282: Is XFAIL == Excepted to fail? In that case it's only 99 problems | 12:23 |
olofk | How do I run the tests manually? Just or1k-elf-g++ <flags> <file.C> with the flags that are listed in the pastie? | 12:39 |
olofk | If that is the way to do it, I get errors for multiple definitions of __getreent when building forced1.C (just picked a random testcase) | 12:41 |
olofk | And if that is the real problem I just found that this was discussed by pgavin, blueCmd and wallento1 in July on comp.hardware.openrisc | 12:45 |
olofk | (standard disclosure: I don't know what the fuck I'm really doing) | 12:45 |
simoncook | Is this GCC regression? | 12:47 |
olofk | ehmm... is that list just tracking openrisc@lists.openrisc.net? | 12:47 |
olofk | simoncook: Yes, I suppose | 12:47 |
olofk | Haven't compared to the or32 gcc 4.5 test results. Do you know if they are easily accessible somewhere? | 12:49 |
simoncook | You can use the test infrastructure to run a subset of tests with e.g. 'runtest --tool=gcc --directory={gcc.c-torture} --srcdir={/path/to/tests} --target_board={boardname} {testfile}.exp={regex_for_tests_to_run}' replacing the variables as appropriate. | 12:53 |
olofk | ah.. cool. I'll try that. Never tried setting up the dejagnu stuff | 12:53 |
simoncook | Not sure where I would find those results, though if anyone has any recent test results, would be interested in seeing them. | 12:54 |
olofk | But should it be --tool=gcc for the g++ tests? | 12:54 |
simoncook | ed-jones is currently doing some work here producing some results, so would be good to compare. Also he may be able to help with any dejagnu issues | 12:54 |
simoncook | that depends on the start of the directory tests are found in | 12:54 |
simoncook | if its g++.something, then --tool=g++ would be needed | 12:55 |
olofk | simoncook: I think stekern, blueCmd or poke53282 pasted some comprehensive test results quite recently | 12:55 |
simoncook | (and we're also working on regression results for the LLVM compiler using GCC's test suite to compare which may be of interest at orconf) | 12:56 |
olofk | Cool. That would be awesome to take a look at | 12:56 |
olofk | Is srcdir the path to or1k-gcc/gcc/testsuite ? | 12:57 |
simoncook | Yes | 12:57 |
ed-jones | olofk, I've been having the same issue with __reent | 13:00 |
simoncook | Oh, and to answer your original question, XFAIL is expected to fail, not to be confused with XPASS which is an unexpected pass. | 13:00 |
olofk | ed-jones, poke53282 : So I guess fixing that would make some more tests pass | 13:01 |
olofk | Or can we cheat and use another libc than newlib? | 13:01 |
simoncook | (and ed-jones is frantically checking through his notebook looking for the explaination of this he wrote down yesterday about this) | 13:01 |
olofk | haha | 13:01 |
ed-jones | seemed a large portion of the test failures were because of getreent multiple definitions | 13:02 |
olofk | I guess that is good news since there's even a proposed fix on the mailing list | 13:02 |
ed-jones | ah, I'd not seen that | 13:02 |
olofk | ed-jones: http://lists.openrisc.net/pipermail/openrisc/2014-July/002228.html in case you didn't see it before | 13:32 |
ed-jones | thanks, not tried any of the fixes suggested | 13:41 |
ed-jones | yet... | 13:41 |
olofk | From what I can read, blueCmd's way of just commenting out the definition in getreent.c seems to be a valid solution | 13:44 |
ed-jones | I got the impression that was a common definition for all archs so would cause problems for everything but or1k | 13:53 |
olofk | oh.. right. Tha | 14:16 |
olofk | t was in the arch-common code | 14:16 |
olofk | simoncook: What should go in the --target_board parameter to runtest? I tried or1ksim | 14:18 |
olofk | hmmm... I suspect there is a bunch of more stuff to set up | 14:21 |
simoncook | The name of a target that dejagnu understands how to communicate with | 14:22 |
simoncook | Usually you would set the DEJAGNU environment variable to the path to some site.exp, and then that file would describe directories where to look for the target board | 14:24 |
simoncook | I can't remember the exact location where these dejagnu files originated, but what ed-jones and I have been doing is using the copy of files I have in https://github.com/simonpcook/or1k-tooling, setting DEJAGNU to the full path to site-sim.exp and then the board would be or1k-elf-sim | 14:26 |
olofk | g++.dg/ext/strncpy-chk1.C <== This looks like a real error. Compiles without optimization but fails with O2 | 14:35 |
olofk | simoncook: Cool. This is one of the areas where a small tutorial would be handy | 14:36 |
simoncook | Indeed, tbh I have to keep looking this up every time I come back to testing a platform I haven't in a while. It sounds like it may be worth making this part of my talk about toolchains at orconf | 14:38 |
olofk | aha.. there is already an or1k workaround for that | 14:38 |
olofk | simoncook: That would be great. | 14:38 |
olofk | Are the or1k-specific workarounds in strncpy-chk1.C that were introduced here still valid? https://github.com/openrisc/or1k-gcc/commit/ddb9f9e4605f35fdb8178e85923ddae92a4231da | 14:46 |
stekern | olofk: poke53282 probably ran the tests against musl | 14:49 |
stekern | olofk: I pretty much have a kernel driver for wb_streamer now | 15:13 |
stekern | we just have to agree on some upper level wrapper interface for multiple channels | 15:14 |
poke53282 | blueCmd, stekern, ed-jones: olofk: Yes, I run the test against musl and with qemu as emulator. It's still unsure whether the atomnic operations are correct implemented or not. blueCmd knows more. | 16:17 |
poke53282 | I will give you a link to the complete test results | 16:18 |
poke53282 | But I would say, that the first error is the most critical one. | 16:19 |
poke53282 | And at the moment I don't what xfail means. Wait | 16:21 |
stekern | poke53282: the "g++-bprob-1.gcda does not exist"? | 16:21 |
olofk | stekern: (driver) Cool. What options are you considering? Got the code somewhere? | 16:23 |
olofk | poke53282: XFAIL == Expected fail. Those are not errors | 16:24 |
stekern | olofk: of course I got the code somewhere, on my harddrive ;) | 16:25 |
olofk | stekern: Ah..stupid me. I forgot to check there :) | 16:26 |
blueCmd | poke53282: not sure I know more actually | 16:26 |
stekern | olofk: I need to clean it up before pushing even an initial version somewhere, but this is the WIP: http://pastie.org/9591186 | 16:27 |
stekern | very heavily based on this: http://lxr.free-electrons.com/source/drivers/dma/dma-jz4740.c | 16:28 |
olofk | Perhaps I should install musl too. Any quick instructions available? | 16:28 |
poke53282 | musl cross from stekern github site. | 16:28 |
poke53282 | just run build.sh | 16:29 |
poke53282 | http://www.jor1k.com/gcc-g++.sum | 16:31 |
poke53282 | here also with statistics | 16:31 |
poke53282 | I omitted the complete list of passes. | 16:32 |
poke53282 | But this place will longer than pastie. | 16:32 |
olofk | I guess that unexpected passes would be interesting too | 16:33 |
poke53282 | olofk: Ok, so I will remove them. | 16:33 |
olofk | remove? You mean add? | 16:33 |
olofk | I'm interested in FAIL and XPASS | 16:34 |
poke53282 | I will remove them from the list. | 16:35 |
poke53282 | Ok, then I will change my grep command and also include XPASS :) | 16:35 |
poke53282 | Shared library: [libc.so] | 16:35 |
olofk | Yes, s/XFAIL/XPASS and I'm happy | 16:36 |
* blueCmd is happy to see people are working on regression tests | 16:36 | |
blueCmd | thanks guys | 16:36 |
olofk | blueCmd: Yeah, you've been doing a lot of work on this upstreaming crap, so it's good to be able to help out with the last parts | 16:37 |
olofk | help out == finding problems and not knowing what to do, in my case :) | 16:38 |
poke53282 | cat gcc.sum | grep FAIL | grep -v XFAIL;cat gcc.sum | grep XPASS | 16:38 |
stekern | olofk: the options I consider are 1) use a dma wrapper top file that includes all the wb_streamers in the soc as seperate channels, all handled by one instance of that driver. 2) use a top wrapper that includes 1 writer and 1 reader and hardcode the driver to two channels (1 tx and 1 rx). 3) assume only one channel per instantiation of the driver | 16:39 |
simoncook | what is the state of upstreaming? I saw mentioned some was occuring a while back but I've been regrettably too busy to really keep up to date on things | 16:40 |
poke53282 | http://www.jor1k.com/gcc-g++.sum | 16:41 |
poke53282 | I have updated the link | 16:41 |
olofk | stekern: Tricky. All options make sense in their own way | 16:41 |
poke53282 | I think, you can ignore the options in or1k-sim. It uses definitely musl and not newlib and not or1k-elf. | 16:42 |
blueCmd | olofk: yeah, it's very time consuming and it's nice to see that people care about this upstreaming :) | 16:42 |
olofk | stekern: Option 1 is like a central DMA controller. I'm leaning a bit towards 2, since we can't make a proper DMA implementation with 3, right? | 16:44 |
olofk | simoncook: We are missing copyright assignments from two people. One of them we can't get hold of, but fortunately her contributions are limited to a few FP additions so can survive without them | 16:45 |
poke53282 | stekern: I copy the executable to my sysroot. Maybe this test case needs an additional file? | 16:45 |
olofk | simoncook: We haven't got a reviewer yet, so if you know any, that would be great | 16:46 |
olofk | poke53282: It seems to require gprof | 16:46 |
poke53282 | I would suggest then, that you ignore the error for now :) | 16:47 |
olofk | stekern: With 'proper DMA implementation' I mean a combined writer and reader that can move data between memory locations | 16:47 |
simoncook | this being GCC? Joern is coming to orconf so he may be able to, or alternatively he may know who may be able to help | 16:47 |
simoncook | (disguised as one of the 4 simoncooks ;)) | 16:48 |
olofk | simoncook: Yes, this is for GCC. Binutils is done, and we're interested in upstreaming GDB, newlib and some other part of our or1k-src tree that I can't remember right now | 16:48 |
olofk | simoncook: That's so sneaky :) | 16:49 |
olofk | Why did I get or1k-linux-musl-* and or1k-musl-linux-* files? | 16:52 |
poke53282 | they are symlinked | 16:53 |
olofk | It's not like I had a shortage of toolchains already | 16:53 |
olofk | aha | 16:53 |
poke53282 | musl-cross does this. | 16:53 |
olofk | Ok, might as well create linux-musl-or1k and the other combinations as well | 16:54 |
poke53282 | No, he is not doing this | 16:54 |
poke53282 | I think, the author of this software wants to confuse everybody. | 16:55 |
poke53282 | just for fun. | 16:55 |
poke53282 | stekern: http://pastie.org/9591246 | 16:58 |
poke53282 | This is my emulator script. | 16:58 |
poke53282 | It gets the executable as an argument from dejagnu and returns an error code. | 16:59 |
poke53282 | Is this enough? | 16:59 |
poke53282 | Or should I copy something back? | 16:59 |
simoncook | The only other thing you might want is copying the rest of argv, but thats not strictly needed for most testing | 17:02 |
poke53282 | chroot $SYSROOT /usr/bin/qemu-or1k-static $b $2 $3 $4 $5 $6 | 17:03 |
poke53282 | This should do it, or? | 17:03 |
poke53282 | But I think, I told dejagnu, that arguments are not allowed | 17:03 |
poke53282 | set_board_info noargs 1 | 17:04 |
simoncook | ok in that case yeah all you need is what you already have, take executable name and return the return code | 17:05 |
poke53282 | olofk: This is how I created my sysroot: https://github.com/s-macke/jor1k/wiki/How-to-develop-for-jor1k#chroot-into-an-emulated-sysroot-environment | 17:08 |
blueCmd | https://github.com/bluecmd/or1k-devel/blob/master/tests/turnup.sh my regression turnup script for running on cloud VMs, so it assumes very few things | 17:25 |
stekern | blueCmd: umm... why did you rip out the floating point stuff from the or1k-gcc repo? | 17:26 |
stekern | I mean from the or1k branch | 17:26 |
blueCmd | stekern: because I was unable to get hold of the author to secure an assignment to GNU | 17:29 |
blueCmd | strictly speaking I wouldn't need to rip it out of our gcc, but only the one going upstream but I'm not a big fan of divergence | 17:30 |
poke53282 | blueCmd: set_board_info cflags "-fprofile-dir=." | 17:32 |
poke53282 | Maybe this will solve some of the FAILED tests, which I have? | 17:32 |
poke53282 | Let me try | 17:33 |
blueCmd | maybe | 17:33 |
stekern | I'm not a big fan of what you just did... | 17:34 |
stekern | blueCmd: did you pinpoint what you removed to her contributions and the rest of the floating point stuff to juliusb? | 17:56 |
blueCmd | stekern: that commit was the only commit attributed to her, sadly it was both her and julius in the commit | 18:08 |
blueCmd | that commit added the copyright statement in the header | 18:08 |
stekern | ok, so basically the compare and double float stuff | 18:11 |
blueCmd | stekern: the cool stuff is that everything that's in our repository is OK for upstreaming save one person | 18:13 |
blueCmd | so even if we stop here, when the final person signs picking up in the future will just be looking at contributors from today and onwards | 18:14 |
stekern | yeah, that's nice. and I can agree on removing it from our current 'master branch' for the reason that it might prevent people from accidently looking at it | 18:16 |
stekern | ...what I don't like is that people that are currently using it will have broken hard-float support for their development | 18:18 |
stekern | (e.g. Andrey) | 18:18 |
stekern | ...but let's keep it as it is now, I anyways pushed the tree before your revert to a or1k-float branch that those can use | 18:19 |
blueCmd | stekern: agreed, we could have it as a branch I guess | 18:20 |
stekern | speaker-test just gives me "Write error: -32,Broken pipe" together with noise... | 18:27 |
poke53282 | stekern, olofk, simoncook: Indeed, he creates those .gcda files in the folder. I have changed my script that he copies those files back. Let's see. I will provide you the new test results, when it is finished. | 18:30 |
poke53282 | But it looks, that this part is an small error in gcc. He should not try those tests. | 18:31 |
poke53282 | stekern: Don't know. http://equalarea.com/paul/alsa-audio.html | 18:32 |
poke53282 | The way to give alsa the audio data is via snd_pcm_writei | 18:33 |
poke53282 | So I guess, some error in your dma code. | 18:34 |
poke53282 | try "speaker-test -t sine" | 18:34 |
poke53282 | stekern: the bare speaker-test should give you just noise. | 18:34 |
stekern | poke53282: speaker-test -r 48000 -c 1 -F S32_LE -t sine | 18:36 |
stekern | err -c 2 | 18:36 |
stekern | that's what I'm using | 18:36 |
poke53282 | well, if you get noise I would try S32-BE. But I guess, that you already tried that ;) | 18:38 |
poke53282 | I can just tell you, that I got for a few ms the correct output from this speaker-test. So, it's definitely an error in the kernel and not in speaker-test | 18:40 |
stekern | yes, and it seems like I get underruns anyway | 18:40 |
poke53282 | But be careful. | 18:40 |
poke53282 | there are several conversions possible. | 18:40 |
poke53282 | Loock in your coded file | 18:41 |
stekern | yeah, I don't doubt that the speaker-test works like it should | 18:41 |
poke53282 | and especially your FMTS flags. | 18:41 |
poke53282 | codec file I mean | 18:41 |
poke53282 | So, I am not sure, what those options to speaker-test really mean. Or if the kernel or alsa-lib make an internal conversion of the data. | 18:42 |
poke53282 | I got those write errors too by the way and much more errors. | 18:46 |
stekern | hmmm... this looks suspicous: http://lxr.free-electrons.com/source/drivers/dma/dma-jz4740.c#L360 | 18:52 |
poke53282 | Sigh, proc/cpuinfo still doesn't work. I don't have a clue | 19:06 |
poke53282 | I get caught in an endless loop. | 19:10 |
poke53282 | and no output and no way out. | 19:10 |
poke53282 | hmm, what's at 0xC0000100? | 19:25 |
poke53282 | so he ends up in an endless loop in the reset part. Interesting. | 19:26 |
stekern | oh, I only had a 32 FIFO entries, that maybe explains things | 19:28 |
stekern | I thought I had 1024 | 19:28 |
poke53282 | the l.rfe from the restore_all function jumps to 0xc000011C. This gets interesting. | 19:46 |
poke53282 | from the timer handler | 19:54 |
poke53282 | getting close: The bug happens in seq_read | 20:39 |
poke53282 | for som reason it tries to jump to 0xC00001F0 | 20:43 |
olofk | stekern, blueCmd : Does this mean that hard-float won't work now, or is it strictly limited to doubles? | 20:45 |
blueCmd | no idea, sorry - I just verified that the defaults are still working | 20:56 |
stekern | olofk: hard-float won't work | 21:15 |
poke53282 | arghh, found the error. Stupid stupid mistake | 21:22 |
poke53282 | That's bad. hard float is important. At least for me. | 21:23 |
stekern | poke53282: I'm not going to remove them in the musl branches at least | 21:27 |
stekern | if a majority feels that we should keep the float stuff in the or1k branch, then I think we should | 21:29 |
stekern | otoh, I wonder how much sense the "you have seen the old code so you can't rewrite it" makes | 21:30 |
stekern | it's mostly boilerplate that can be pretty much copied from other archs | 21:30 |
stekern | I could argue that I already implemented fpu support for or1k in a different compiler before I even looked at gcc internals | 21:31 |
stekern | and that I based the rewrite on that rather than what I've seen later | 21:32 |
poke53282 | stekern, blueCmd, simoncook, olofk, ed-jones: I have updated the summary. http://www.jor1k.com/gcc-g++.sum | 21:47 |
poke53282 | stekern: I hope that wen find a good solution for this problem. | 21:48 |
olofk | poke53282: So we got 727+6 failing tests now | 21:53 |
olofk | ah. that was for g++ | 21:54 |
olofk | 110+1 for gcc | 21:54 |
poke53282 | 110+1+227+6 | 21:54 |
poke53282 | Exactly | 21:54 |
poke53282 | and the first one is the most severe. | 21:54 |
poke53282 | I know, that the torture test was already successful one year ago. | 21:55 |
olofk | Got to sleep now, but I'm sure this will all be resolved when I wake up tomorrow :) | 21:55 |
poke53282 | Lol, good luck | 21:56 |
poke53282 | good night | 21:56 |
poke53282 | olofk: The first error in the torture test is an error of QEMU: "qemu: uncaught target signal 6 (Aborted) - core dumped" | 22:10 |
poke53282 | It runs successful in my emulator. | 22:11 |
--- Log closed Thu Sep 25 00:00:09 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!