IRC logs for #openrisc Wednesday, 2014-04-23

--- Log opened Wed Apr 23 00:00:17 2014
stekernblueCmd: ah, I had already found them, but thanks for the hint03:39
stekernI couldn't find anything wrong with them, so have to be a problem with the kernel. I think that the kregs is not the same as the exception pt_regs03:41
stekernbecause the kregs and userregs are oif course for the cloned thread, not the one that is running03:42
stekernfor a comparison, I'm not using any kregs at all in my eco32 port:
stekernI just use a sepereate cpu_context struct to hold the context for switch_to03:48
stekern_in fact, it's the userregs that hold the current saved context from exception entry04:07
stekern_copied from current_pt_regs()04:08
stekern_so, it should be: userregs->gpr[10] = userregs->gpr[7]04:09
stekernoho! that stekern_ was a handsome devil! =)04:09
stekernblueCmd: when I said, "I don't think that will work" I meant for the or1k port. Not sure if that might work for other archs. Of course the circumstances for it to even work without -fPIC have to be there then.05:06
stekernblueCmd: the ifconfig stack smashing was probably due to the struct padding too, that works now too05:29
blueCmdstekern: ah, I see. weird that it worked for me (or not horribly crashed at least)07:39
blueCmdi did rewrite that patch, maybe the first version was ok and the latter not07:39
blueCmdyeah, that must be it. the first version was:07:41
blueCmd+       if (clone_flags & CLONE_SETTLS)07:41
blueCmd+               childregs->gpr[10] = regs->gpr[7];07:41
stekernah well, it can't be that common that clone is called with CLONE_SETTLS, since everything has worked for me until I tried running irssi07:43
stekern...and there's no 'regs' in copy_thread, so that first verison wouldn't compile ;)07:45
stekernnor childregs, was that located somewhere else then?07:46
blueCmdstekern: it was for an old version of linux07:47
blueCmdthat function looked very different then07:47
blueCmdstekern: any more issues you have found, or is it usable as an IRC box now?07:48
stekernah, yes I see, then pt_regs *regs was passed to copy_thread07:50
stekernand now that have been exchanged with obtaining it from current_pt_regs() instead07:50
stekernI wanted to irc as another user than root, but it won't let me login as anything else07:51
stekern'strace su stefan' finds this: openat(AT_FDCWD, "/proc/self/loginuid", O_RDONLY) = -1 ENOENT (No such file or directory)07:52
ysionneaucome on, root is even better, you get @ on every channels ;)08:22
stekernheh ;)08:36
blueCmdstekern: hm, I'm running as another user in qemu08:55
blueCmdstekern: ah, maybe loginuid is a debian patch thing08:56
blueCmdstekern: if you could try to track the problem down that would be cool :)08:57
stekernthe kernel has some CONFIG_AUDITSYSCALL #ifdef around loginuid09:06
stekernthe strace also complains about missing /dev/log09:07
blueCmdstekern: did you see ?10:55
stekernblueCmd: yes, didn't you see my \o/?11:28
stekernah, no I mean ;)11:42
stekernare you sure that there wasn't any patches touching generic files that was left out?11:43
stekernI think I have seen some changelog in some generic place that ended with .or1k11:45
stekernI have atleast built our or1k-src with enable-cgen-maint recently11:55
stekernI can take a closer look in the evening11:56
blueCmdstekern: thanks12:19
blueCmdstekern: olofk jeremybennett: I got two requests for upstreaming GCC as well now today :)16:12
blueCmdstekern: is the ChangeLog.or1k needed for cgen to generate stuff?17:03
olofkblueCmd: Yeah, it would be great to get the gcc ball rolling. Just need someone to dig through the SVN and git archives17:33
stekernblueCmd: not the changelog, but the changes it mention17:56
blueCmdolofk: yes.. we need.. someone... someone..17:57
blueCmdstekern: maybe that wasn't included, hm17:57
stekernwere those included in the patches?17:58
blueCmdstekern: no changed to cgen what I can see :(17:58
blueCmdchanges* (in the patches)17:58
blueCmd those are the patches17:59
stekernok, hopefully they are not controversal18:00
blueCmdstekern: mind doing a patch for that? otherwise I will do it18:12
stekernthere are some generic changes to sim/ too18:43
stekernah, but we didn't include the sim stuff at all?18:44
stekernmaybe it's better if you put out the patch, you got a better idea of what's been sent and not18:45
blueCmdstekern: sure18:54
blueCmdstekern: I sent the things I used to build the debian package basically18:55
blueCmdI knew that gdb was broken, and I didn't want to send or1ksim18:55
blueCmdnot sending cgen was a misstake, but what is sim used for?18:55
stekernyeah, or1ksim is a definite no19:02
stekernthe sim is a nifty little thing, it's an autogenerated simulator from the cgen description19:03
stekernand it's commonly used to run the gcc regression suite19:05
blueCmdI see19:07
blueCmdstekern: diff -Nur . /srv/or1k-devel/or1k-src -x configure -x -x sim -x gdb -x readline -x .git -x blt -x boards -x cgen -x contrib -x dejagnu -x expat -x expect -x itcl -x iwidgets -x libgloss -x libgui -x mmalloc -x newlib -x proto-toplev -x rda -x README-OR1K -x sid -x site.exp -x tcl -x tix -x tk -x utils -x winsup -x ChangeLog.or1k19:12
blueCmdthat's how I made the patch19:12
stekerni see, I think the rest is ok but cgen and potentially sim19:18
stekernif you want, you can ping peter about it too19:19
blueCmd*sigh* It's a frikken pain to extract these patches19:20
blueCmdprobably easier to just grab the diff on
blueCmdwe should deprecate or1k-src, create or1k-binutils-gdb and make it a fork of the upstream19:23
blueCmdas I understand it, that was the way it was before - i think it makes the life of tracking the changes much easier19:23
stekernthat's the way it is now, upstream, before it was unified in the humongous sourceware cvs repo19:25
stekernbut yes, we should split out newlib and libgloss19:26
blueCmdstekern: do you have any idea where the cgen stuff is? I cannot find it in;a=tree19:42
blueCmd - oh19:43
stekernah, so... those were rightfully omitted binutils patches I guess?19:45
stekern+from the19:45
stekerndo cgen have an own ml?19:46
stekern...I think it does19:46
stekerniirc juliusb sent mails to that with questions when he was working on this stuff19:46
blueCmdyes, I think I excluded it because the patch wasn't a patch19:46
blueCmdsim looks fine patch-wise though19:47
stekernthe patch wasn't a patch?19:47
blueCmdhah, it makes sense!19:48
blueCmdthe resulting patch of the diff wouldn't have been a patch but a copy19:48
blueCmd*sigh* that doesn't make sense either, hopefully you can puzzle something together19:49
stekernpatch it together, you mean?19:54
stekernthe loginuid was a red herring19:54
blueCmdwhen doing the diff between or1k-src and upstream I excluded stuff that was out-of-tree, which would have included gen19:54
blueCmdstekern: oh?19:55
stekernah, I see20:07
stekernyeah, I hack-enabled CONFIG_AUDITSYSCALL, which gives me the loginuid file20:09
stekernbut the result is the same20:09
stekernhowever, if I do 'su -s /bin/dash stefan' I get a dash shell20:10
stekern... and every command get served with a 'killed' message20:10
stekernit doesn't work if I change the shell in /etc/passwd20:11
blueCmdI wonder what happens if you run the "uid" binary I told you to run20:21
blueCmdas a shell or something20:21
stekernthe one that printed 0 0 0?20:25
blueCmdit should print 1000 1000 1000 for your user20:26
stekernyup, let's see what it does when I find it20:26
blueCmdstekern: that's cgen20:28
stekernso it is ;)20:31
blueCmdI guess I just post it to the very active mailinglist20:36
stekernI take that as irony20:37
stekernno luck running the uid binary...20:38
stekernwas there a logsave in initramfs/bin before I did: sudo cp hacks/logsave initramfs/bin20:43
blueCmdstekern: yes!20:45
blueCmdthere was20:45
blueCmdyou shouldn't do that20:45
blueCmdthat's an old instruction20:46
stekernyes, I noticed that you have removed that20:46
blueCmdah good20:46
blueCmdreinstall e2fsprogs20:46
blueCmdor whatever the name is for that thing20:46
stekernbut you pushed that after I had followed your old instruction20:46
stekern...that I have already done, but there's no logsave in /bin20:47
stekernthere is however one in /sbin/20:47
blueCmdjust remove the dummy one then20:51
stekernthat I have also done20:51
stekernso, I think I'm all good20:51
stekernis there any syslogd that we can use?20:53
blueCmdI'll see what I can do20:56
stekernbecause I guess su is trying to tell me something when it tries to open /dev/log20:58
stekernand I'd like to know what20:58
blueCmdtouch /dev/log ? :)21:05
stekernmnja, it wants it to be a socket me thinks21:06
blueCmdstekern: apt-get install rsyslog22:18
--- Log closed Thu Apr 24 00:00:19 2014

Generated by 2.15.2 by Marius Gedminas - find it at!