IRC logs for #openrisc Wednesday, 2014-09-24

--- Log opened Wed Sep 24 00:00:07 2014
poke53282to set up dejagnu took only one hour. A improvement by a factor of ten in comparison to last year01:22
poke53282The current errors02:41
poke53282stekern: "cat /proc/cpuinfo" . Does it work?03:37
stekernpoke53282: yes:
poke53282is smp active?05:45
poke53282I haven't compiled it in.05:46
stekernpoke53282: it works with it compiled in and not06:25
poke53282Ok, thanks06: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 Munich08:52
stekernFatty Acid Ester meeting?09:30
_franck__almost :)09:43
stekerneither way, good news! ;)09:57
sb0what'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 now12:21
olofkpoke53282: Is XFAIL == Excepted to fail? In that case it's only 99 problems12:23
olofkHow do I run the tests manually? Just or1k-elf-g++ <flags> <file.C> with the flags that are listed in the pastie?12:39
olofkIf 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
olofkAnd if that is the real problem I just found that this was discussed by pgavin, blueCmd and wallento1 in July on comp.hardware.openrisc12:45
olofk(standard disclosure: I don't know what the fuck I'm really doing)12:45
simoncookIs this GCC regression?12:47
olofkehmm... is that list just tracking
olofksimoncook: Yes, I suppose12:47
olofkHaven't compared to the or32 gcc 4.5 test results. Do you know if they are easily accessible somewhere?12:49
simoncookYou 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
olofkah.. cool. I'll try that. Never tried setting up the dejagnu stuff12:53
simoncookNot sure where I would find those results, though if anyone has any recent test results, would be interested in seeing them.12:54
olofkBut should it be --tool=gcc for the g++ tests?12:54
simoncooked-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 issues12:54
simoncookthat depends on the start of the directory tests are found in12:54
simoncookif its g++.something, then --tool=g++ would be needed12:55
olofksimoncook: I think stekern, blueCmd or poke53282 pasted some comprehensive test results quite recently12: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
olofkCool. That would be awesome to take a look at12:56
olofkIs srcdir the path to or1k-gcc/gcc/testsuite ?12:57
ed-jonesolofk, I've been having the same issue with __reent13:00
simoncookOh, and to answer your original question, XFAIL is expected to fail, not to be confused with XPASS which is an unexpected pass.13:00
olofked-jones, poke53282 : So I guess fixing that would make some more tests pass13:01
olofkOr 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
ed-jonesseemed a large portion of the test failures were because of getreent multiple definitions13:02
olofkI guess that is good news since there's even a proposed fix on the mailing list13:02
ed-jonesah, I'd not seen that13:02
olofked-jones: in case you didn't see it before13:32
ed-jonesthanks, not tried any of the fixes suggested13:41
olofkFrom what I can read, blueCmd's way of just commenting out the definition in getreent.c seems to be a valid solution13:44
ed-jonesI got the impression that was a common definition for all archs so would cause problems for everything but or1k13:53
olofkoh.. right. Tha14:16
olofkt was in the arch-common code14:16
olofksimoncook: What should go in the --target_board parameter to runtest? I tried or1ksim14:18
olofkhmmm... I suspect there is a bunch of more stuff to set up14:21
simoncookThe name of a target that dejagnu understands how to communicate with14:22
simoncookUsually 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 board14:24
simoncookI 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, setting DEJAGNU to the full path to site-sim.exp and then the board would be or1k-elf-sim14:26
olofk g++.dg/ext/strncpy-chk1.C <== This looks like a real error. Compiles without optimization but fails with O214:35
olofksimoncook: Cool. This is one of the areas where a small tutorial would be handy14:36
simoncookIndeed, 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 orconf14:38
olofkaha.. there is already an or1k workaround for that14:38
olofksimoncook: That would be great.14:38
olofkAre the or1k-specific workarounds in strncpy-chk1.C that were introduced here still valid?
stekernolofk: poke53282 probably ran the tests against musl14:49
stekernolofk: I pretty much have a kernel driver for wb_streamer now15:13
stekernwe just have to agree on some upper level wrapper interface for multiple channels15:14
poke53282blueCmd, 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
poke53282I will give you a link to the complete test results16:18
poke53282But I would say, that the first error is the most critical one.16:19
poke53282And at the moment I don't what xfail means. Wait16:21
stekernpoke53282: the "g++-bprob-1.gcda does not exist"?16:21
olofkstekern: (driver) Cool. What options are you considering? Got the code somewhere?16:23
olofkpoke53282: XFAIL == Expected fail. Those are not errors16:24
stekernolofk: of course I got the code somewhere, on my harddrive ;)16:25
olofkstekern: Ah..stupid me. I forgot to check there :)16:26
blueCmdpoke53282: not sure I know more actually16:26
stekernolofk: I need to clean it up before pushing even an initial version somewhere, but this is the WIP:
stekernvery heavily based on this:
olofkPerhaps I should install musl too. Any quick instructions available?16:28
poke53282musl cross from stekern github site.16:28
poke53282just run build.sh16:29
poke53282here also with statistics16:31
poke53282I omitted the complete list of passes.16:32
poke53282But this place will longer than pastie.16:32
olofkI guess that unexpected passes would be interesting too16:33
poke53282olofk: Ok, so I will remove them.16:33
olofkremove? You mean add?16:33
olofkI'm interested in FAIL and XPASS16:34
poke53282I will remove them from the list.16:35
poke53282Ok, then I will change my grep command and also include XPASS :)16:35
poke53282 Shared library: []16:35
olofkYes, s/XFAIL/XPASS and I'm happy16:36
* blueCmd is happy to see people are working on regression tests16:36
blueCmdthanks guys16:36
olofkblueCmd: 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 parts16:37
olofkhelp 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 XPASS16:38
stekernolofk: 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 driver16:39
simoncookwhat 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 things16:40
poke53282I have updated the link16:41
olofkstekern: Tricky. All options make sense in their own way16:41
poke53282I think, you can ignore the options in or1k-sim. It uses definitely musl and not newlib and not or1k-elf.16:42
blueCmdolofk: yeah, it's very time consuming and it's nice to see that people care about this upstreaming :)16:42
olofkstekern: 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
olofksimoncook: 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 them16:45
poke53282stekern: I copy the executable to my sysroot. Maybe this test case needs an additional file?16:45
olofksimoncook: We haven't got a reviewer yet, so if you know any, that would be great16:46
olofkpoke53282: It seems to require gprof16:46
poke53282I would suggest then, that you ignore the error for now :)16:47
olofkstekern: With 'proper DMA implementation' I mean a combined writer and reader that can move data between memory locations16:47
simoncookthis being GCC? Joern is coming to orconf so he may be able to, or alternatively he may know who may be able to help16:47
simoncook(disguised as one of the 4 simoncooks ;))16:48
olofksimoncook: 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 now16:48
olofksimoncook: That's so sneaky :)16:49
olofkWhy did I get or1k-linux-musl-* and or1k-musl-linux-* files?16:52
poke53282they are symlinked16:53
olofkIt's not like I had a shortage of toolchains already16:53
poke53282musl-cross does this.16:53
olofkOk, might as well create linux-musl-or1k and the other combinations as well16:54
poke53282No, he is not doing this16:54
poke53282I think, the author of this software wants to confuse everybody.16:55
poke53282just for fun.16:55
poke53282This is my emulator script.16:58
poke53282It gets the executable as an argument from dejagnu and returns an error code.16:59
poke53282Is this enough?16:59
poke53282Or should I copy something back?16:59
simoncookThe only other thing you might want is copying the rest of argv, but thats not strictly needed for most testing17:02
poke53282chroot $SYSROOT /usr/bin/qemu-or1k-static $b $2 $3 $4 $5 $617:03
poke53282This should do it, or?17:03
poke53282But I think, I told dejagnu, that arguments are not allowed17:03
poke53282set_board_info noargs 117:04
simoncookok in that case yeah all you need is what you already have, take executable name and return the return code17:05
poke53282olofk: This is how I created my sysroot:
blueCmd my regression turnup script for running on cloud VMs, so it assumes very few things17:25
stekernblueCmd: umm... why did you rip out the floating point stuff from the or1k-gcc repo?17:26
stekernI mean from the or1k branch17:26
blueCmdstekern: because I was unable to get hold of the author to secure an assignment to GNU17:29
blueCmdstrictly 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 divergence17:30
poke53282blueCmd: set_board_info cflags "-fprofile-dir=."17:32
poke53282Maybe this will solve some of the FAILED tests, which I have?17:32
poke53282Let me try17:33
stekernI'm not a big fan of what you just did...17:34
stekernblueCmd: did you pinpoint what you removed to her contributions and the rest of the floating point stuff to juliusb?17:56
blueCmdstekern: that commit was the only commit attributed to her, sadly it was both her and julius in the commit18:08
blueCmdthat commit added the copyright statement in the header18:08
stekernok, so basically the compare and double float stuff18:11
blueCmdstekern: the cool stuff is that everything that's in our repository is OK for upstreaming save one person18:13
blueCmdso even if we stop here, when the final person signs picking up in the future will just be looking at contributors from today and onwards18:14
stekernyeah, 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 it18:16
stekern...what I don't like is that people that are currently using it will have broken hard-float support for their development18: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 use18:19
blueCmdstekern: agreed, we could have it as a branch I guess18:20
stekernspeaker-test just gives me "Write error: -32,Broken pipe" together with noise...18:27
poke53282stekern, 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
poke53282But it looks, that this part is an small error in gcc. He should not try those tests.18:31
poke53282stekern: Don't know.
poke53282The way to give alsa the audio data is via snd_pcm_writei18:33
poke53282So I guess, some error in your dma code.18:34
poke53282try "speaker-test -t sine"18:34
poke53282stekern: the bare speaker-test should give you just noise.18:34
stekernpoke53282: speaker-test -r 48000 -c 1 -F S32_LE -t sine18:36
stekernerr -c 218:36
stekernthat's what I'm using18:36
poke53282well, if you get noise I would try S32-BE. But I guess, that you already tried that ;)18:38
poke53282I 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-test18:40
stekernyes, and it seems like I get underruns anyway18:40
poke53282But be careful.18:40
poke53282there are several conversions possible.18:40
poke53282Loock in your coded file18:41
stekernyeah, I don't doubt that the speaker-test works like it should18:41
poke53282and especially your FMTS flags.18:41
poke53282codec file I mean18:41
poke53282So, 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
poke53282I got those write errors too by the way and much more errors.18:46
stekernhmmm... this looks suspicous:
poke53282Sigh, proc/cpuinfo still doesn't work. I don't have a clue19:06
poke53282I get caught in an endless loop.19:10
poke53282and no output and no way out.19:10
poke53282hmm, what's at 0xC0000100?19:25
poke53282so he ends up in an endless loop in the reset part. Interesting.19:26
stekernoh, I only had a 32 FIFO entries, that maybe explains things19:28
stekernI thought I had 102419:28
poke53282the l.rfe from the restore_all function jumps to 0xc000011C. This gets interesting.19:46
poke53282from the timer handler19:54
poke53282getting close: The bug happens in seq_read20:39
poke53282for som reason it tries to jump to 0xC00001F020:43
olofkstekern, blueCmd : Does this mean that hard-float won't work now, or is it strictly limited to doubles?20:45
blueCmdno idea, sorry - I just verified that the defaults are still working20:56
stekernolofk: hard-float won't work21:15
poke53282arghh, found the error. Stupid stupid mistake21:22
poke53282That's bad. hard float is important. At least for me.21:23
stekernpoke53282: I'm not going to remove them in the musl branches at least21:27
stekernif a majority feels that we should keep the float stuff in the or1k branch, then I think we should21:29
stekernotoh, I wonder how much sense the "you have seen the old code so you can't rewrite it" makes21:30
stekernit's mostly boilerplate that can be pretty much copied from other archs21:30
stekernI could argue that I already implemented fpu support for or1k in a different compiler before I even looked at gcc internals21:31
stekernand that I based the rewrite on that rather than what I've seen later21:32
poke53282stekern, blueCmd, simoncook, olofk, ed-jones: I have updated the summary.
poke53282stekern: I hope that wen find a good solution for this problem.21:48
olofkpoke53282: So we got 727+6 failing tests now21:53
olofkah. that was for g++21:54
olofk110+1 for gcc21:54
poke53282and the first one is the most severe.21:54
poke53282I know, that the torture test was already successful one year ago.21:55
olofkGot to sleep now, but I'm sure this will all be resolved when I wake up tomorrow :)21:55
poke53282Lol, good luck21:56
poke53282good night21:56
poke53282olofk: The first error in the torture test is an error of QEMU: "qemu: uncaught target signal 6 (Aborted) - core dumped"22:10
poke53282It runs successful in my emulator.22:11
--- Log closed Thu Sep 25 00:00:09 2014

Generated by 2.15.2 by Marius Gedminas - find it at!