IRC logs for #openrisc Tuesday, 2013-02-12

-!- Kevin`_ is now known as Kevin`02:35
blueCmdrunning the test suite on GCC w/ eglibc removes some fails10:32
blueCmd < diff of errors in stekerns run and my run10:35
jonibouClibc is not upstream and I won't push it until the generic syscall interfaces are in place... that's been a pain to get upstreamed though as there have been 3 attempts by 3 different people already but still no upstream acceptance... the ImagTech "Meta" architecture folks are working on it now... there should be no copyright issues, though, with getting that upstream12:36
blueCmdjonibo: oh, I just figured out that you're Jonas!12:37
blueCmdgeneric syscall interfaces?12:38
joniboor "numbering" is perhaps a better word12:38
blueCmdis that by chance related to vfork and such abominations?12:38
jonibokind of12:38
jonibovfork is deprecated12:38
joniboit's been replaced by clone12:38
joniboso new Linux arch's don't have vfork anymore12:39
joniboincluding openrisc12:39
joniboall new arch's use the same numbers for their syscalls12:39
joniboand none of them implement the "old", deprecated syscalls12:39
jonibothey're kind of "clean"12:40
blueCmdwell I just submitted my strace patch to upstream, it's easy enough to update though12:40
joniboyeah, I just saw12:42
jonibothe list of syscalls is too long12:42
joniboa bunch of them don't exist12:42
jonibodoes strace not have the "generic" list yet?12:42
joniboif it does, you need to use it12:42
jonibootherwise, you should remove all the deprecated symbols12:42
blueCmdjonibo: I figured out that I missed or1k_atomic (or w/e it's called) too. In the shower of all places.12:44
blueCmdjonibo: hm, I didn't find any generic list when I looked, but then again I did most of my code scouting in 4.7 before realising how old it was12:45
jonibofeel free to CC me on stuff like that interfaces to kernel... a lot of userspace packages still reflect the "old" way of doing things whereas OpenRISC really only has the "new" kernel interfaces12:45
joniboi'll grab strace and take a look12:46
blueCmdjonibo: sure, will do.12:46
blueCmdI think the patches are a bit mangled in the email - I found out that gmail enforces 78 char line wrapping12:48
blueCmdit should only be in 2-3 places though12:48
jonibogit email is the only thing that works12:48
blueCmdHm, yeah - I assume I will need to figure out how to set that up12:49
blueCmdjonibo: (feel free to continue use english in your emails, probably easiest for me as well)12:50
jonibowill do12:51
blueCmdregarding eglibc - the generic syscall mapping there is the one that "Just Works" right? I have written like maximum 5 syscalls where we have some arch specific things.12:52
joniboyeah, it should be the one that just works12:53
jonibothere should be 1 syscall that's special... or1k_atomic12:53
jonibowhat are the other 4?12:53
blueCmdwell, it's not really the syscalls per say12:54
blueCmdit's more our ELF ABI12:54
blueCmdeglibc exports (for example) prctl as prctl(int option, ...)12:54
blueCmdi.e. as an vararg function12:54
blueCmdthe syscall interface requires arguments in the regs12:54
blueCmdvarargs use stack12:54
blueCmdso I needed to create wrappers for those12:55
jonibothere's some syscall that has a union argument, too, that's a pain to get right12:55
jonibosemctl, I think12:55
jonibothe ABI pass unions by reference isn't what we want for a syscall so you need to cast to a void * when making the syscall12:56
blueCmdyepp, haven't noticed that one - that will need fixing as well12:56
joniboanyway, sounds like you've got it all under control12:56
joniboI check now and strace doesn't have the generic syscall list yet... you could add it12:56
joniboaarch64 's list is the one to copy and pare down a bit, in that case, as they are using the generic numbering as well12:57
joniboI didn't see any other "new" arch's in there, otherwise12:57
blueCmdwhat do you mean by generic in that sense?12:58
blueCmdwe do not use the same numbers as aarch6412:58
jonibono?  we should have the same numbers as aarch6412:59
blueCmdeglibc uses the __NR_xx constants IIRC12:59
joniboyeah, and for all "new" architectures those nubmers are the same12:59
blueCmdnope, their syscall 0 is restart_syscall, 1 is exit and so on12:59
blueCmdour restart syscall is like 144 or something, exit is 9312:59
blueCmdwell, it included "arm/syscallent.h"12:59
blueCmdso that's the one I'm looking at13:00
blueCmdah right13:00
joniboI don't know why they have 213:00
blueCmd32 bit and 64 bit13:00
jonibowhat they've submitted to the upstream kernel is what's in syscallent113:00
blueCmdpersonality I think?13:00
joniboright, 32 bit and 64 bit13:00
jonibono, not personality, they are really two completely different architectures13:00
jonibonot compatible in any way13:01
blueCmdwell yes this looks like or1ks13:01
joniboyeah, it should be identical13:01
joniboand if you implement that in a "generic" subdirectory, then you've got about 6 or 7 other architctures done as well13:01
jonibothat's a lot of bang for your buck13:01
blueCmd[244 ... 259] = { }, - cool, didn't know that syntax13:02
joniboyou see where it says "Arch-specific block" in their file?  delete everything from there to the end of the file...13:04
jonibothen you'll still need a openrisc version where you #include this file (generic/syscallent.h) and add or1k_atomic13:04
joniboI think that's an elegant solution13:04
blueCmdjonibo: well, 260 - 271 is still in openrisc ?13:04
jonibosorry, of course13:05
joniboyou need those13:05
jonibobut sys_open and the rest of the stuff they've got at the end of the file is all gone13:05
jonibomaking this file generic means that maybe somebody else comes along and fixes it occasionally for their arch and we get the fixes for free... big win!13:06
joniboanyway, i'm going to have some lunch now... back later13:06
blueCmdjonibo: have fun :)13:07
blueCmdjonibo: I misspelled your lastname in a mail to strace-devel list - my apologies!13:58
joniboblueCmd: I saw your patch... looks good.  Tile is _almost_ the generic interface... they have some quirks but they can probably figure that out themselves if you get this generic stuff in there.14:16
blueCmdjonibo: ah14:18
blueCmdthey didn't have process_vm things - but I just glanced through it14:19
blueCmdjonibo: btw, do you recall if you managed to build gdbserver?14:20
jonibocan't remember... I don't think I did14:21
joniboi'm 80% certain I didn't use gdbserver when doing the regset work14:21
blueCmdhm, well it doesn't build natively nor for or3214:21
jonibobit of work to do there then14:21
blueCmdhaha, yeah - probably just merge something from upstream14:22
blueCmddid you run gdb on or32 or just target or32 ?14:22
jonibotarget, I  think14:22
blueCmdi don't expect you to remember, I'm just glad if you do :P14:23
joniboit's been too long... I don't recall the setup I was using... pretty sure it was target14:23
blueCmd_franck_: are you around?14:38
blueCmd_franck_: anyway, when you're building gdb - how do you do that? I tried with or1k-src/gdb/configure but that fails to find bfd.h14:48
blueCmdI think we talked about this before but I don't remeber :(14:48
blueCmd_franck_: nvm, i figured it out!15:04
_franck_blueCmd: great you are working on gdb !15:33
blueCmd_franck_: I figured I want to add -linux support from jonibos work. But I think I will finish and push TLS first - very little left there16:03
blueCmd BAM!16:40
poke53281thanks blueCmd21:02
poke53281One question. Is there a reason why the issue tracker is not activated for the projects? It seems that no one is using the bugzilla website.21:11
poke53281I know it would be better to send directly pull requests to solve bugs.21:15
poke53281But I don't want to work on bugs which someone familiar with the code could solve in 10% of the time.21:17
jeremybennettpoke53281: There is a bug tracker for OpenRISC on the opencores website:
poke53281Yes I know21:20
jeremybennettThe lack of use is more about the number of people involved. The stable tool chain has been around for a while, so it doesn't generate many bugs. The guys working on the development tool chain are so busy just trying to get it to work, I don' tthink they are formally tracking bugs.21:21
poke53281Yes, I know that the lack of people is the main problem.21:32
poke53281I did the last two bug tracker entries #106 and #107 within 3 months and did not receive a response21:32
poke53281which is fine as long as I know that they are recognized in some way by the correct people.21:32
poke53281For me as a developer it would be motivating to get bug responses for my projects.21:32
jeremybennettWhat was the subject of those two entries?21:34
jeremybennettNot all the tools even have active maintainers. Bug reports about binutils may not get much response.21:34
poke53281more or less actively developed as far as I see in the commit messages.21:35
jeremybennettHow embarrassing - 107 is assigned to me!21:35
jeremybennettI'm not the right person to be the default assignee for GCC. I think I just get anything that no one else picks up.21:36
jeremybennettI'm not sure who the best person is to pass it on to though. I'll ask on the mailing list.21:36
poke53281According to the commit history it is at the moment blueCmd and skristiansson.21:38
jeremybennettOK - I'll see if one of them will volunteer to be the default GCC bug recipient.21:39
jeremybennettJust posted to the mailing list.21:39
jeremybennettThe Linux bug is assigned to jonibo, which seems right to me.21:39
poke53281Therefore it is Ok if I don't get a response. But if it is not even read by someone then the bugzilla website can be shutdown.21:40
poke53281Yes I expected this.21:40
poke53281Thank jeremybennett21:41
jeremybennettWell, it took a long time to get bugzilla up and running - the old issue tracker was a nightmare. And some bugs *do* get fixed where there are active maintainers. What's needed is more volunteers to maintain tools!21:42
jeremybennettBTW - they bugs are read by me, because I get an automatic email for each one. But I have no bandwidth to deal with them!21:43
poke53281Maybe if I get a message like "Problem reproducible, but there are other issues which are more important", this would motivate me to send pull requests by my own.21:50
poke53281then it more easy for the maintainers.21:51
andresjkDoes anyone knows why "Segmentation fault" occurs? I have compiled some apps using scanf and the or32-linux-gcc and I get that msg when executing23:41
_franck_in general, it's because you're accessing an address you're not allowed23:45
_franck_aren't you dereferencing a null pointer ?23:45
andresjknot really. The code its to simple. I dont even use pointers23:47
andresjk#include "stdio.h"23:47
andresjkvoid main(void)23:47
andresjk int num;23:47
andresjkwhile(1) {23:47
andresjkscanf("%d, &num");23:47
andresjkprintf("Number was: %d \n", num);23:47
_franck_last time you were asking me about scanf you were using the elf toolchain right ?23:51
blueCmdandresjk: scanf("%d, &num"); should be scanf("%d", &num);23:51
blueCmdpretty sure the compiler would warn about that one23:53
andresjkyeah, my bad. elf is for bare metal right. I actually used elf-gcc once for a printf within linux and It worked. weird23:53
andresjkblueCmd, letme try it out23:53

Generated by 2.15.2 by Marius Gedminas - find it at!