IRC logs for #openrisc Sunday, 2012-12-23

stekernblueCmd: your patches didn't cause any new regressions, so I've commited them.07:48
stekerna couple of things for the future: please add ChangeLog entries (I've previously been lazy in that department as well, but I just corrected some of my missing once)07:49
stekernI took the liberty to add changelog entries for those two patches in your name, hope you don't mind.07:50
stekernand the second thing: when you do a pull request, do that in a seperate branch. Because any commits to the branch you have done to the branch that you do the pull request for will be added to the pull request.07:52
stekernthis is a bit confusing when doing github pull requests, but they are really no different from a manual pull request sent by (for example) e-mail.07:53
stekernNo biggie in this case, I just manually picked the commit you had in the original pull request (the first one) from this:
stekernbut just so you know in the future07:55
blueCmdstekern: the changelog: check, I actually came to ask about that just now - but will do in the future13:38
blueCmdstekern: right, that wouldn't have been a problem on or1k-gcc ? I think i did just that on that request13:39
blueCmdyeah I see now - the request you linked above looks really awefull - sorry about that :) Oh well, learning is fun!13:40
blueCmdstekern: thanks for merging btw!13:44
blueCmdstekern: btw, regarding dejagnu testing. wouldn't it be easier to use like qemu now when openrisc is supported?13:49
blueCmdI'm assuming all the ftp + telnet is really doing is uploading files and running them reading/writing output/input13:50
jeremybennettblueCmd: For testing, it makes sense to use a) Or1ksim because that is the golden reference for the architecture behaviour and b) the actual hardware (as FPGA or Verilog model).14:07
jeremybennettThe difference between the two has in the past been a useful way of identifying hardware bugs. By GCC 4.5.1, we had the two regression sets identical.14:07
jeremybennettIf you are not familiar with DejaGnu testing, here is a tutorial:
blueCmdjeremybennett: I suppose, I just feel that it would create an environment that's 1) easier to setup and 2) less complex (and thus inherently less likely to fail).14:08
blueCmdbut I see your point14:08
jeremybennettThe Or1ksim environment is already set up, so that should be easiest of all :)14:09
blueCmdah, is it? I thought or1ksim was the simulator14:09
stekernblueCmd: yes, you can use qemu as well, I've tested running the regression suite against it14:10
jeremybennettWith the latest gcc 4.8 you should be able to run against the CGEN simulator. Comparing against Or1ksim is a useful validation of the CGEN simulator we have yet to do.14:10
jeremybennettstekern: Did you get the same results as with Or1ksim?14:10
stekernjeremybennett: this is the linux toolchain, so you need or1ksim/qemu14:11
stekernjeremybennett: yes, same result14:11
jeremybennettAh - of course.14:12
stekernbut I prefer or1ksim with it's tracing features14:12
jeremybennettstekern: That is excellent validation of the QEMU simulator.14:12
blueCmdstekern: i'm refering to qemu-user, are you?14:12
stekernblueCmd: no, I ran emulation of "full" machine14:13
stekern could be a fun excocise14:13
blueCmdah right, that would require the same hassle of having to compile a linux kernel and full userspace14:13
blueCmd(i have a kernel, no userspace - perhaps you have that precompiled somewhere?)14:14
stekernrunning under full qemu was also slower (for some odd reason) than under or1ksim14:14
blueCmdstekern: weird, I would expect the reverse14:14
stekernI do have a setup I can share, but I am away from a normal computer until tomorrow14:15
blueCmdstekern: hah, no sweat, I won't be hacking that much over xmas anyway :)14:16
blueCmdIt just showpoints my case that using qemu-user would be benefitial to all new developers to quickly be able to do reg. testing14:16
stekernyeah, I agree, it's been on my todo-list to investigate that14:23
stekernwould be good for cross-building as well14:23
stekernfeel free to beat me to it and rmeove it from my todo-list though ;)14:24
blueCmdyes - my long term goal is building debian for openrisc, I just recently googled qemu and openrisc and was pleasnly surprised that it was mainline14:24
stekernyup, Jia did a good job with that14:25
blueCmdstekern: hah, I will see what I can do - I have a couple of patches to gcc that makes the output more or less identical to that of x86_64 (.eh_frame, .eh_frame_hdr and stuff like that). I suppose that's a good thing, but it was required for glibc support aswell. Anyway, I don't have the courage to send you a pull request without properly testing those ;)14:26
blueCmdstekern: indeed14:26
stekernsounds good, we are failing a bunch of eh tests, not sure that's related  to eh_frame at all, but the hope is what dies last ;)14:29
blueCmdI don't think that eh was populated at all before these patches, not sure though.14:29
blueCmdso maybe, just maybe, it will fix something :P14:30
blueCmdoh well, time to eat lots of xmas food I suppose. bbl14:30
blueCmdstekern: btw, if you feel like it you're free to pull from my branch of or1k-src and or1k-gcc (bluecmd/master on both) and see if it solves anything, would be fun to know14:31
stekernok, I'll take a look. after xmas is over ;)16:28
--- Log closed Sun Dec 23 18:30:10 2012
--- Log opened Sun Dec 23 18:30:27 2012
-!- Irssi: #openrisc: Total of 20 nicks [0 ops, 0 halfops, 0 voices, 20 normal]18:30
-!- Irssi: Join to #openrisc was synced in 23 secs18:30
olofkIs anyone going to the DVclub thing in Bristol or Cambridge January 14?19:57
_franck_what is this checkpatch error:22:22
_franck_any idea ? "need consistent spacing around '*' (ctx:WxV)"22:23
_franck_just a space to add after that '*' it was confusing because the whole use that construct and does not have this space here22:46

Generated by 2.15.2 by Marius Gedminas - find it at!