| -!- Kevin`_ is now known as Kevin` | 02:35 | |
| blueCmd | running the test suite on GCC w/ eglibc removes some fails | 10:32 |
|---|---|---|
| blueCmd | http://c56f71cf12f4423b.paste.se/ < diff of errors in stekerns run and my run | 10:35 |
| jonibo | uClibc 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 upstream | 12:36 |
| blueCmd | jonibo: oh, I just figured out that you're Jonas! | 12:37 |
| jonibo | :) | 12:37 |
| blueCmd | generic syscall interfaces? | 12:38 |
| jonibo | or "numbering" is perhaps a better word | 12:38 |
| blueCmd | is that by chance related to vfork and such abominations? | 12:38 |
| jonibo | kind of | 12:38 |
| jonibo | vfork is deprecated | 12:38 |
| jonibo | it's been replaced by clone | 12:38 |
| blueCmd | yeah | 12:39 |
| jonibo | so new Linux arch's don't have vfork anymore | 12:39 |
| jonibo | including openrisc | 12:39 |
| jonibo | all new arch's use the same numbers for their syscalls | 12:39 |
| jonibo | and none of them implement the "old", deprecated syscalls | 12:39 |
| jonibo | they're kind of "clean" | 12:40 |
| blueCmd | well I just submitted my strace patch to upstream, it's easy enough to update though | 12:40 |
| jonibo | yeah, I just saw | 12:42 |
| jonibo | the list of syscalls is too long | 12:42 |
| jonibo | a bunch of them don't exist | 12:42 |
| jonibo | does strace not have the "generic" list yet? | 12:42 |
| jonibo | if it does, you need to use it | 12:42 |
| jonibo | otherwise, you should remove all the deprecated symbols | 12:42 |
| blueCmd | jonibo: I figured out that I missed or1k_atomic (or w/e it's called) too. In the shower of all places. | 12:44 |
| blueCmd | jonibo: 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 was | 12:45 |
| jonibo | feel 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 interfaces | 12:45 |
| jonibo | i'll grab strace and take a look | 12:46 |
| blueCmd | jonibo: sure, will do. | 12:46 |
| blueCmd | I think the patches are a bit mangled in the email - I found out that gmail enforces 78 char line wrapping | 12:48 |
| blueCmd | it should only be in 2-3 places though | 12:48 |
| jonibo | git email is the only thing that works | 12:48 |
| blueCmd | Hm, yeah - I assume I will need to figure out how to set that up | 12:49 |
| blueCmd | jonibo: (feel free to continue use english in your emails, probably easiest for me as well) | 12:50 |
| jonibo | will do | 12:51 |
| blueCmd | regarding 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 |
| jonibo | yeah, it should be the one that just works | 12:53 |
| jonibo | there should be 1 syscall that's special... or1k_atomic | 12:53 |
| jonibo | what are the other 4? | 12:53 |
| blueCmd | well, it's not really the syscalls per say | 12:54 |
| blueCmd | it's more our ELF ABI | 12:54 |
| blueCmd | eglibc exports (for example) prctl as prctl(int option, ...) | 12:54 |
| blueCmd | i.e. as an vararg function | 12:54 |
| jonibo | right | 12:54 |
| blueCmd | the syscall interface requires arguments in the regs | 12:54 |
| blueCmd | varargs use stack | 12:54 |
| jonibo | yeah | 12:55 |
| blueCmd | so I needed to create wrappers for those | 12:55 |
| jonibo | there's some syscall that has a union argument, too, that's a pain to get right | 12:55 |
| jonibo | semctl, I think | 12:55 |
| jonibo | the ABI pass unions by reference isn't what we want for a syscall so you need to cast to a void * when making the syscall | 12:56 |
| blueCmd | yepp, haven't noticed that one - that will need fixing as well | 12:56 |
| jonibo | anyway, sounds like you've got it all under control | 12:56 |
| jonibo | I check now and strace doesn't have the generic syscall list yet... you could add it | 12:56 |
| jonibo | aarch64 's list is the one to copy and pare down a bit, in that case, as they are using the generic numbering as well | 12:57 |
| jonibo | I didn't see any other "new" arch's in there, otherwise | 12:57 |
| blueCmd | what do you mean by generic in that sense? | 12:58 |
| blueCmd | we do not use the same numbers as aarch64 | 12:58 |
| jonibo | no? we should have the same numbers as aarch64 | 12:59 |
| blueCmd | eglibc uses the __NR_xx constants IIRC | 12:59 |
| jonibo | yeah, and for all "new" architectures those nubmers are the same | 12:59 |
| blueCmd | nope, their syscall 0 is restart_syscall, 1 is exit and so on | 12:59 |
| blueCmd | our restart syscall is like 144 or something, exit is 93 | 12:59 |
| jonibo | aarch64? | 12:59 |
| blueCmd | well, it included "arm/syscallent.h" | 12:59 |
| blueCmd | so that's the one I'm looking at | 13:00 |
| jonibo | syscallent1.h | 13:00 |
| blueCmd | ah right | 13:00 |
| jonibo | I don't know why they have 2 | 13:00 |
| blueCmd | 32 bit and 64 bit | 13:00 |
| jonibo | what they've submitted to the upstream kernel is what's in syscallent1 | 13:00 |
| blueCmd | personality I think? | 13:00 |
| jonibo | right, 32 bit and 64 bit | 13:00 |
| jonibo | no, not personality, they are really two completely different architectures | 13:00 |
| jonibo | not compatible in any way | 13:01 |
| blueCmd | aha | 13:01 |
| blueCmd | well yes this looks like or1ks | 13:01 |
| jonibo | yeah, it should be identical | 13:01 |
| jonibo | and if you implement that in a "generic" subdirectory, then you've got about 6 or 7 other architctures done as well | 13:01 |
| jonibo | that's a lot of bang for your buck | 13:01 |
| blueCmd | yep | 13:02 |
| blueCmd | [244 ... 259] = { }, - cool, didn't know that syntax | 13:02 |
| jonibo | you see where it says "Arch-specific block" in their file? delete everything from there to the end of the file... | 13:04 |
| jonibo | then you'll still need a openrisc version where you #include this file (generic/syscallent.h) and add or1k_atomic | 13:04 |
| jonibo | I think that's an elegant solution | 13:04 |
| blueCmd | jonibo: well, 260 - 271 is still in openrisc ? | 13:04 |
| jonibo | sorry, of course | 13:05 |
| jonibo | you need those | 13:05 |
| jonibo | but sys_open and the rest of the stuff they've got at the end of the file is all gone | 13:05 |
| jonibo | making 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 |
| jonibo | anyway, i'm going to have some lunch now... back later | 13:06 |
| blueCmd | jonibo: have fun :) | 13:07 |
| blueCmd | jonibo: I misspelled your lastname in a mail to strace-devel list - my apologies! | 13:58 |
| jonibo | blueCmd: 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 |
| blueCmd | jonibo: ah | 14:18 |
| blueCmd | they didn't have process_vm things - but I just glanced through it | 14:19 |
| blueCmd | jonibo: btw, do you recall if you managed to build gdbserver? | 14:20 |
| jonibo | can't remember... I don't think I did | 14:21 |
| jonibo | i'm 80% certain I didn't use gdbserver when doing the regset work | 14:21 |
| blueCmd | hm, well it doesn't build natively nor for or32 | 14:21 |
| jonibo | ok | 14:21 |
| jonibo | bit of work to do there then | 14:21 |
| blueCmd | haha, yeah - probably just merge something from upstream | 14:22 |
| blueCmd | did you run gdb on or32 or just target or32 ? | 14:22 |
| jonibo | target, I think | 14:22 |
| blueCmd | i don't expect you to remember, I'm just glad if you do :P | 14:23 |
| jonibo | it's been too long... I don't recall the setup I was using... pretty sure it was target | 14:23 |
| jonibo | :) | 14: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.h | 14:48 |
| blueCmd | I 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 there | 16:03 |
| blueCmd | https://github.com/openrisc/or1k-src/commit/25cf517d18159128241368a20e19efd10e5302cc BAM! | 16:40 |
| poke53281 | thanks blueCmd | 21:02 |
| poke53281 | One question. Is there a reason why the issue tracker is not activated for the https://github.com/openrisc projects? It seems that no one is using the bugzilla website. | 21:11 |
| poke53281 | I know it would be better to send directly pull requests to solve bugs. | 21:15 |
| poke53281 | But I don't want to work on bugs which someone familiar with the code could solve in 10% of the time. | 21:17 |
| jeremybennett | poke53281: There is a bug tracker for OpenRISC on the opencores website: http://bugzilla.opencores.org/ | 21:20 |
| poke53281 | Yes I know | 21:20 |
| jeremybennett | The 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 |
| poke53281 | Yes, I know that the lack of people is the main problem. | 21:32 |
| poke53281 | I did the last two bug tracker entries #106 and #107 within 3 months and did not receive a response | 21:32 |
| poke53281 | which is fine as long as I know that they are recognized in some way by the correct people. | 21:32 |
| poke53281 | For me as a developer it would be motivating to get bug responses for my projects. | 21:32 |
| jeremybennett | What was the subject of those two entries? | 21:34 |
| jeremybennett | Not all the tools even have active maintainers. Bug reports about binutils may not get much response. | 21:34 |
| poke53281 | http://bugzilla.opencores.org/bugzilla4/show_bug.cgi?id=107 | 21:34 |
| poke53281 | http://bugzilla.opencores.org/bugzilla4/show_bug.cgi?id=106 | 21:34 |
| poke53281 | more or less actively developed as far as I see in the commit messages. | 21:35 |
| jeremybennett | How embarrassing - 107 is assigned to me! | 21:35 |
| jeremybennett | I'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 |
| jeremybennett | I'm not sure who the best person is to pass it on to though. I'll ask on the mailing list. | 21:36 |
| poke53281 | According to the commit history it is at the moment blueCmd and skristiansson. | 21:38 |
| jeremybennett | OK - I'll see if one of them will volunteer to be the default GCC bug recipient. | 21:39 |
| jeremybennett | Just posted to the mailing list. | 21:39 |
| jeremybennett | The Linux bug is assigned to jonibo, which seems right to me. | 21:39 |
| poke53281 | Therefore 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 |
| poke53281 | Yes I expected this. | 21:40 |
| poke53281 | Thank jeremybennett | 21:41 |
| jeremybennett | Well, 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 |
| jeremybennett | BTW - 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 |
| poke53281 | Maybe 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 |
| poke53281 | then it more easy for the maintainers. | 21:51 |
| andresjk | Does anyone knows why "Segmentation fault" occurs? I have compiled some apps using scanf and the or32-linux-gcc and I get that msg when executing | 23:41 |
| _franck_ | in general, it's because you're accessing an address you're not allowed | 23:45 |
| _franck_ | aren't you dereferencing a null pointer ? | 23:45 |
| andresjk | not really. The code its to simple. I dont even use pointers | 23:47 |
| andresjk | #include "stdio.h" | 23:47 |
| andresjk | void main(void) | 23:47 |
| andresjk | { | 23:47 |
| andresjk | int num; | 23:47 |
| andresjk | while(1) { | 23:47 |
| andresjk | scanf("%d, &num"); | 23:47 |
| andresjk | printf("Number was: %d \n", num); | 23:47 |
| andresjk | num=0; | 23:47 |
| andresjk | } | 23:47 |
| andresjk | } | 23:47 |
| _franck_ | last time you were asking me about scanf you were using the elf toolchain right ? | 23:51 |
| blueCmd | andresjk: scanf("%d, &num"); should be scanf("%d", &num); | 23:51 |
| blueCmd | no? | 23:52 |
| blueCmd | pretty sure the compiler would warn about that one | 23:53 |
| andresjk | yeah, my bad. elf is for bare metal right. I actually used elf-gcc once for a printf within linux and It worked. weird | 23:53 |
| andresjk | blueCmd, letme try it out | 23:53 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!