| --- Log opened Tue Apr 22 00:00:16 2014 | ||
| stekern | it ends with a lookup for setrlimit64 | 03:48 |
|---|---|---|
| stekern | olofk_: you are too quick to respond, I've already pushed that orpsocv2 patch and was writing an answer | 06:31 |
| stekern | but I wanted to create the atlys pull request first, so we could boost with a more concrete atlys port in progress ;) | 06:32 |
| olofk_ | Sorry about that. Slow day at work :) | 06:32 |
| stekern | maybe I'll just pretend I didn't see your answer and just send my message as is ;) | 06:33 |
| olofk_ | Yeah. Do that. Sounds easiest | 06:34 |
| olofk_ | (and is probably what I would have done if I had started writing already) | 06:34 |
| stekern | at least it escalated the atlys board port =) | 06:45 |
| stekern | ...and no-one can blame us for being non-responsive and letting patches queue up for eternity anymore ;) | 06:56 |
| stekern | olofk_: so, if you've got a slow day at work, spend some time browsing through the pull-requst ;) | 07:06 |
| stekern | it's not as clean as I'd like it to be, but I think it might just sit around and bitrot until I get around to clean it up... | 07:07 |
| stekern | who will do the honor of doing the 100th commit? https://github.com/openrisc/orpsoc-cores | 07:16 |
| olofk_ | stekern: You can still blame me for being non-responsive. Five open pull requests for orpsoc-cores and one for fusesoc :) | 07:24 |
| olofk_ | But I'll check the atlys one quickly. Don't worry about it not being clean enough. We can fix that later. | 07:24 |
| olofk_ | I should probably have told _franck__ to submit his port too instead of cleaning it up. Perfect is the enemy of done | 07:26 |
| olofk_ | What? Three ps/2 slaves? Is there even three ps/2 ports on the board? | 07:28 |
| stekern | no, or well, yes... on my board there is | 07:28 |
| stekern | one goes to the PMOD connector, and two goes to the usb_hid<->ps2 converter | 07:29 |
| stekern | in theory, it should be possible to use mouse and keyboard through the usb connector, but you'll need one of those devices that have both implemented | 07:30 |
| stekern | i.e. a hub doesn't work | 07:31 |
| stekern | like one of these would work: http://g-ecx.images-amazon.com/images/G/01/aplus/detail-page/B005DKZTMG_K400_FOB_US_lg.jpg | 07:31 |
| blueCmd | stekern: i see. i have had some problems with setlocale, thats why im asking | 07:32 |
| stekern | blueCmd: que? | 07:32 |
| blueCmd | irssi and ld dbug | 07:33 |
| stekern | ah, ok | 07:33 |
| olofk_ | stekern: I think you will have the honor to submit commit #100 | 07:34 |
| stekern | olofk_: I'll take a screenshot, print it and put it on a wall! | 07:35 |
| olofk_ | :) | 07:35 |
| olofk_ | Achievement unlocked! | 07:35 |
| _franck_web_ | olofk_: don't worry I'm almost done :) | 07:38 |
| _franck_web_ | stekern: can you push your DTS file too with your atlys board ? | 07:40 |
| * _franck_web_ is looking for the best way to implement a whishbone clock crossing bridge | 07:41 | |
| blueCmd | stekern: solved the pass 2 btw. MPFR compiles with only 19 test failures instead of 65 now :) | 07:42 |
| olofk_ | _franck_web_: Yes. A wishbone CDC would be great to have as a stand-alone component. We talked about trying to lift out the one from stekern's wb_sdram_ctrl, but I haven't investigated if that could be done easily | 07:44 |
| olofk_ | Unfortunately Wishbone B3 isn't very well suited for CDC. Wishbone B4 fixes that to some extent | 07:44 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-gcc/commit/dee30337198e40c58f0b75014f939702dd5e86d4 | 07:45 |
| stekern | blueCmd: sounds good | 07:56 |
| olofk_ | So what's the binutls status now? | 08:19 |
| olofk_ | Have everyone got their signed papers back? | 08:19 |
| stekern | olofk_: what's in wb b4 that makes cdc easier? | 08:21 |
| stekern | the irssi bug is an unaligned access somewhere... | 08:32 |
| blueCmd | stekern: really? that's cool | 08:34 |
| blueCmd | I wonder what that might be | 08:34 |
| blueCmd | it might just be memory pointer corruption also | 08:34 |
| stekern | yup | 08:36 |
| stekern | and that it sometimes crashes with a bus error makes that theory even more plausible | 08:36 |
| blueCmd | that we managed solving the TLS bug makes me feel nice. I really thought giving up for a moment. | 08:38 |
| blueCmd | probably spent 80 hours on the damn thing :) | 08:38 |
| stekern | moments like that, I always start thinking "damn, if I give up now, then I have wasted 80h for nothing" ;) | 08:39 |
| stekern | GPR09: 6765745f <- that doesn't look good | 08:39 |
| blueCmd | hah | 08:40 |
| stekern | from: http://pastie.org/9099843 | 08:40 |
| blueCmd | looks like a perfectly good return address to me | 08:40 |
| blueCmd | it just needs extra attention | 08:40 |
| LoneTech | binascii.a2b_hex('6765745f') | 08:41 |
| LoneTech | 'get_' | 08:41 |
| blueCmd | LoneTech: nice catch! | 08:41 |
| stekern | haha, LoneTech is probably the only one that can read ascii in hex on the fly ;) | 08:41 |
| LoneTech | far from it, and I didn't bother. enough that most of it was letters. | 08:42 |
| stekern | don't be modest | 08:42 |
| LoneTech | why not? | 08:42 |
| blueCmd | I mean, you have a nice thing there to be able to see that in an instant | 08:42 |
| LoneTech | I keep working on bits. it's mere habit | 08:43 |
| LoneTech | gpr2 also holds probable text (nel_) | 08:44 |
| stekern | yeah, which means that it's not only r9 that's trashed | 08:45 |
| stekern | ...well, r2 oculd potentially hold something like that in a function where the framepointer is omitted | 08:45 |
| stekern | let's see what's happening at 000be4a4 | 08:46 |
| olofk_ | stekern: B4 doesn't make it easier. Just more efficient as you don't have to wait for an ack for each access | 08:48 |
| LoneTech | the alignment of nel_ doesn't match the many get_kernel_page* symbols | 08:49 |
| stekern | be4a4: 44 00 48 00 l.jr r9 | 08:49 |
| LoneTech | yep, return to get_ | 08:50 |
| stekern | olofk_: you mean in the pipeline mode | 08:50 |
| olofk_ | stekern: Yep. | 08:50 |
| stekern | yeah, so our problem is that our registers aren't large enough to hold the full string for the return address... | 08:51 |
| LoneTech | lol | 08:51 |
| olofk_ | I told you that we should have stored our registers in the cloud so we could scale them easier | 08:51 |
| stekern | mor1kx ms edition does that | 08:52 |
| olofk_ | :) | 08:52 |
| LoneTech | irssi symbol: channel_get_nickmode | 08:52 |
| LoneTech | does match up with the alignment | 08:52 |
| stekern | that looks plausible | 08:52 |
| stekern | be4a4 is in core_init | 08:53 |
| stekern | maybe the stack pointer is getting trashed, since r9 is loaded from there | 08:53 |
| blueCmd | sounds very plausible. trashed and makes r9 load some old string value | 08:54 |
| stekern | this is interesting though, framepointer isn't omitted in that function and: http://pastie.org/9099885 | 08:56 |
| stekern | ah, that wasn't as interesting as I first thought | 08:56 |
| stekern | but it explains the nice alignment of r2 and r9 | 08:57 |
| LoneTech | or restores frame pointer into stack pointer afaict | 08:57 |
| LoneTech | yep, frame pointer was trashed before restoring the stack frame | 08:57 |
| LoneTech | (as it happens, to a value pointing into the symbol table) | 08:57 |
| stekern | I think I should take up on my own advice and run core_init in or1ksim surrounded with l.trap 8 and l.trap 9 | 08:58 |
| stekern | err, l.nop I mean | 09:02 |
| stekern | olofk_: what board is it that you are making a port for btw? | 09:07 |
| stekern | http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm | 09:08 |
| stekern | that? | 09:08 |
| blueCmd | we should set up some regression testing for board support | 09:15 |
| blueCmd | mark a couple 'officially supported' and make sure we test them | 09:15 |
| blueCmd | should be possible to automate | 09:15 |
| stekern | at least booting on the atlys board is magnitudes faster than or1ksim | 09:27 |
| blueCmd | that makes me happy! | 09:31 |
| stekern | LoneTech: didn't you have a patch to make or1ksim 'term' sane? | 09:36 |
| LoneTech | I don't recall right now. I probably poked at something way back | 09:37 |
| LoneTech | I've found one diff to xterm.c that probably messed with that | 09:38 |
| LoneTech | I suspect I copied it from somewhere because it mentions cygwin | 09:39 |
| LoneTech | http://donkey.vernier.se/~yann/openrisc-public/or1ksim-xterm.diff | 09:40 |
| stekern | thanks | 09:44 |
| LoneTech | if that thing helps someone should document what it helps with and check it in | 09:48 |
| LoneTech | (incidentally, what it does could probably be done by connecting stty(1) to the xterm) | 09:49 |
| olofk_ | stekern: Yep. That's the board | 09:53 |
| olofk_ | blueCmd: Yeah. I agree. Need someone to buy them and somewhere to host them though. | 09:55 |
| blueCmd | stekern: if you submit stuff to or1ksim, would you mind testing my pull request as well? | 09:55 |
| blueCmd | i added random MAC generation | 09:56 |
| blueCmd | jeremybennett wanted (rightfully so) me to run the testsuite, but I haven't gotten around to compile an -elf compiler | 09:57 |
| olofk_ | 34 cores in orpsoc-cores so far. Not bad at all | 10:02 |
| stekern | bah... and then there's those 64-bit fixes that haven't made it into or1ksim too... | 10:10 |
| stekern | https://github.com/pgavin/or1ksim/commit/6a33f2aee910b07d4261e297a35f3c83c60a66a7 | 10:11 |
| stekern | blueCmd: sure, I can do that | 10:12 |
| stekern | I can pull in that and peters 64-bit fix and ask jeremybennett if it's ok to push those together with my atomic changes when it's time for them to go in | 10:17 |
| olofk_ | What's the status on OpenRISC in qemu? Can we use the mainline version or do we have a lot of local patches? | 10:28 |
| stekern | I've got a nice little 1.6 gig trace to sift through now... | 10:43 |
| stekern | olofk_: I think it's largely ok, iirc the most critical patches from poke53281 got merged | 10:44 |
| stekern | I think blueCmd's patches are mostly related to running glibc in usermode qemu, right? | 10:45 |
| blueCmd | stekern: yes, but I'm using poke53281's patches to build my patches on | 10:48 |
| stekern | I think I see an interesting thing in the 1.6gig trace | 10:52 |
| LoneTech | do tell | 10:52 |
| stekern | this is the correct value that get saved away: | 10:52 |
| stekern | U 000be268: 9c410000 l.addi r2,r1,0x0 r2 = 7fc2dccc flag: 0 | 10:52 |
| stekern | this is the trashed value: GPR01: 0000dccc | 10:53 |
| stekern | where did those upper bits go? | 10:53 |
| LoneTech | addi should not destroy them. andi would | 10:54 |
| stekern | ah, yes, but there are about 1.6 gig of trace between those two events ;) | 10:55 |
| LoneTech | wonderful. so search on the address bus? | 10:55 |
| stekern | but I've got a feeling that I've found the right haystack to search the needle in | 10:56 |
| stekern | +for | 10:57 |
| LoneTech | good | 10:57 |
| stekern | looks like it's the uname syscall that trashes the stack | 11:56 |
| LoneTech | that structure has changed size in different versions, as indicated by linux/utsname.h having oldold_utsname, old_utsname and new_utsname | 12:05 |
| stekern | yes, that's what I'm starting to think about | 12:07 |
| stekern | from the disasm, linux does a copy_to_user with 392 bytes | 12:07 |
| stekern | ...and the stack that is getting trashed is at byte 391 and 392 | 12:11 |
| stekern | umm... where does those 2 extra bytes come from... | 12:21 |
| stekern | if I go by this: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/include/uapi/linux/utsname.h | 12:21 |
| stekern | the size of struct new_utsname should be 6*65 = 390 | 12:22 |
| LoneTech | yes, that's what it looks like it would be in userspace. somehow the kernel didn't agree. | 12:29 |
| stekern | yes, this might be a or32-linux-gcc thing though... it somehow thinks that struct new_utsname is 392 bytes | 12:30 |
| stekern | http://pastie.org/9100276 | 12:30 |
| stekern | let's see if recompiling it with the or1k-elf- makes a difference | 12:32 |
| stekern | seems odd that it would pad it with 2 bytes though... | 12:32 |
| stekern | to something that's not aligned to 4 I mean | 12:33 |
| stekern | or... errr | 12:33 |
| stekern | that's what it does, pad it to something that's aligned to 4 | 12:33 |
| * stekern goes back to the schoolbench to learn some basic math | 12:34 | |
| stekern | and blueCmd fiddled with the struct padding in gcc | 12:35 |
| stekern | ...the gcc he have used to compile userspace with I mean | 12:36 |
| blueCmd | yrd | 12:38 |
| blueCmd | yes* | 12:38 |
| blueCmd | parts of userspace! | 12:38 |
| blueCmd | :) | 12:38 |
| blueCmd | libc would have been compiled before that alignment thing | 12:38 |
| stekern | hmm, could be a or32- vs or1k- difference without your fiddling though | 12:39 |
| stekern | unless the pointer to the utsname struct comes from irssi | 12:40 |
| stekern | ...which it probably does | 12:41 |
| stekern | my or1k-elf-gcc pads it up to 392 too | 12:44 |
| blueCmd | so apparently we have successfully assigned copyright to GNU for binutils | 12:44 |
| stekern | ...so, I take back what I said about the struct padding ;) | 12:50 |
| blueCmd | so, what's the problem? | 12:56 |
| blueCmd | I haven't read the discussions with much detail | 12:56 |
| stekern | the problem is that userspace gives the kernel an area of 390 bytes to copy the struct into, but the kernel copies the padded struct that is 392 bytes | 13:15 |
| stekern | I can of course make the problem go away by compiling the kernel with your struct pad patch applied | 13:17 |
| blueCmd | aha | 13:19 |
| blueCmd | I think you should do that :) | 13:19 |
| blueCmd | stekern: how does it run in general? bug aside, does it feel useful? I'm afraid it's too slow to be useful, but with atomic instructions and possibly vDSO I hope it will be useable even at 50 MHz | 13:26 |
| _franck_web_ | what do you think of simple handshake CDC like this: http://picpaste.com/pics/7c20a4a6b7b94a2263711d64079a6ec5.1398174541.png | 13:50 |
| _franck_web_ | that would not be efficient | 13:51 |
| stekern | blueCmd: heh, yeah, I'll probably do that for now, but we probably have to give that patch some more thought | 13:56 |
| stekern | what was the problem you had that it solves? | 13:57 |
| stekern | blueCmd: usable? my x64 desktop is already halfways out the window! =) | 14:00 |
| blueCmd | stekern: hah! nice to hear | 14:01 |
| blueCmd | stekern: it solves stuff like file formats and network structures. stuff like freetype has compile time asserts on the size of structures | 14:02 |
| blueCmd | and not attribute((packed)) | 14:02 |
| blueCmd | not sure if that is a correct assumption by them, but I'm not going to rewrite freetype | 14:03 |
| stekern | I guess it depend on what you expect, but it's probably usable enough for some low demand tasks | 14:04 |
| stekern | that's why I want to get irssi working | 14:05 |
| stekern | apt-getting is snappy enough (if you don't count update) | 14:06 |
| olofk_ | stekern: I'm still waiting for you to do a emerge -uND world :) | 14:10 |
| olofk_ | _franck_web_: I'm not sure that would be enough. I'm a bit scared of sending all those lines between the clock domains without dedicated synchronization registers | 14:12 |
| blueCmd | olofk_: you mean 'wine WindowsUpdate.exe'? | 14:14 |
| olofk_ | :) | 14:18 |
| blueCmd | now that's a killer app | 14:19 |
| _franck_web_ | olofk_: all those non registered lines are stable when cyc and stb are active. Plus, cyc and stb go thru some dff and are delayed | 14:19 |
| stekern | yeah, I think that should be ok | 14:20 |
| blueCmd | stekern: running make CFLAGS='-fPIC' check on mpfr makes all tests succeed | 14:27 |
| blueCmd | so I guess I missed some PIC emit somewhere | 14:27 |
| stekern | (rewrite freetype) slacker! | 14:32 |
| stekern | yeah, I guess the upsides might win over the downsides then... | 14:33 |
| blueCmd | stekern: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=73589c9dbddc7906fa6a150f2a2a0ff6b746e8ba | 15:24 |
| blueCmd | olofk_: also ofc | 15:24 |
| -!- phoohb_ is now known as phoohb | 15:28 | |
| stekern | \o/ | 15:41 |
| Limb | olofk: I got the BSCAN working on the artix7, yes | 17:56 |
| stekern | now irssi starts, but segfaults when trying to connect | 18:19 |
| stekern | this time it's somewhere in a lib | 18:20 |
| stekern | in libpthread.so.0 to be more preices | 18:23 |
| stekern | precise, something my writing isn't... | 18:24 |
| blueCmd | stekern: interesting! | 18:24 |
| stekern | this little irc client is a tough beast to get running ;) | 18:26 |
| stekern | it's nice to have glibc, that have support for all the LD_* env-vars | 18:27 |
| blueCmd | I'm enjoying that you are discovering bugs, it's nice to not be the only one xD | 18:28 |
| stekern | I'm enjoying fixing bugs more than discovering them ;) | 18:29 |
| stekern | otoh, discovering is often the hardest part | 18:29 |
| stekern | blueCmd: hmm, r10 is read in start_thread, but it's zero | 19:01 |
| stekern | which makes me suspect that the TLS stuff in copy_thread might not work right | 19:02 |
| blueCmd | stekern: interesting | 19:06 |
| blueCmd | stekern: you have the full https://github.com/bluecmd/or1k-linux/commit/00ca771fb532b9a7877fef4b4b45f18d19c54c92 right? | 19:07 |
| stekern | yes | 19:09 |
| stekern | unless you have changed something in the atomic patch since what you've posted to the ml, but's not related now | 19:10 |
| blueCmd | right, no that should be fine I think | 19:10 |
| blueCmd | if you could see if kregs->gpr[7] is a "pointer looking value" that would be neat | 19:11 |
| stekern | hmm, I guess I could dig that out, but I don't have it available right now | 19:14 |
| blueCmd | oh well | 19:15 |
| stekern | what emits the read from r10? | 19:15 |
| stekern | trying to find the place where that happens in the C version of start_thread | 19:16 |
| _franck__ | stekern: could you show me your ps2 device tree binding ? | 19:19 |
| blueCmd | stekern: the code I'm modifying in gcc | 19:19 |
| blueCmd | emit_insn (gen_add3_insn (dest, dest, tp)); | 19:19 |
| blueCmd | or the __tls_get_addr function | 19:20 |
| stekern | hmm... ok... | 19:20 |
| stekern | teach me about tls ;) when does that happen? | 19:21 |
| blueCmd | the emit? | 19:24 |
| stekern | yes, what triggers that | 19:24 |
| blueCmd | when gcc finds a symbol with a TLS model assigned to it | 19:24 |
| blueCmd | which would be a symbol with the '__thread' decl | 19:24 |
| stekern | ok, I see | 19:25 |
| blueCmd | it can either be GLOBAL DYNAMIC (GD), LOCAL DYNAMIC (LD), INITIAL EXEC (IE), LOCAL EXEC (LE) | 19:25 |
| blueCmd | depending on where the symbol is and how it will be linked | 19:26 |
| stekern | ok | 19:26 |
| blueCmd | GD and LD differs somewhat in that the result from tls_get_addr can be cached in LD. IE nad LD can be resolved link-time. | 19:26 |
| blueCmd | GD LD are resolved runtime (dynamic symbols) | 19:26 |
| blueCmd | so an executable you would only have GD or LD relocs (only GD in or1k since I treat LD as GD) | 19:27 |
| blueCmd | but in the .o files you can have all relocs | 19:27 |
| stekern | great, thanks for the explanation | 19:28 |
| blueCmd | np | 19:28 |
| stekern | _franck__: http://pastie.org/9101298#60 | 19:30 |
| _franck__ | stekern: thanks | 19:31 |
| blueCmd | stekern: can we just use llvm instead? | 19:43 |
| blueCmd | throw away gcc | 19:48 |
| stekern | yes, but there's no TLS support in our port ;) | 19:48 |
| blueCmd | who needs TLS? let's just change glibc to use emutls | 19:49 |
| stekern | blueCmd: this doesn't look good in combination with your patch: http://lxr.free-electrons.com/source/arch/openrisc/kernel/entry.S#L1095 | 20:13 |
| stekern | but that doesn't explain why it's 0... | 20:14 |
| blueCmd | stekern: which part? | 20:16 |
| stekern | the part where the stack pointer is copied into argument 5 (r7) | 20:17 |
| blueCmd | line 1095? | 20:19 |
| blueCmd | ah right | 20:19 |
| blueCmd | stekern: I recall this, but somehow it was OK | 20:32 |
| stekern | yeah, I think it is | 20:32 |
| stekern | it should already be saved to kregs on exception entry | 20:32 |
| stekern | so, the question is, why isn't it? | 20:33 |
| stekern | or rather, why is it 0? | 20:33 |
| blueCmd | have you tried in or1ksim? | 20:33 |
| stekern | no, that might be a good idea | 20:34 |
| blueCmd | ofc it is! | 20:34 |
| blueCmd | it starts in qemu btw | 20:34 |
| stekern | irssi? | 20:34 |
| blueCmd | yes | 20:34 |
| stekern | but can you connect? | 20:35 |
| stekern | it starts here too | 20:35 |
| blueCmd | oh, I haven't tried | 20:35 |
| stekern | and then segfaults when I do /connect or /server | 20:35 |
| bluecmd_ | stekern: hello | 20:35 |
| blueCmd | bluecmd_: you are a handsome devil! | 20:36 |
| stekern | =) | 20:37 |
| stekern | is that usermode or 'normal' qemu? | 20:38 |
| blueCmd | usermode | 20:38 |
| stekern | so, most likely a kernel bug if there's a sw bug | 20:39 |
| blueCmd | yes, running in or1ksim should say something | 20:39 |
| blueCmd | if it's sw or hw | 20:39 |
| stekern | I'm recompiling the kernel for or1ksim now | 20:40 |
| blueCmd | this is stupid, things are working but optimization kills it | 20:40 |
| blueCmd | for TLS | 20:40 |
| blueCmd | it tries to wrap everything in a got()(r16) block | 20:41 |
| blueCmd | "because that is obviously the best thing to do" | 20:41 |
| blueCmd | go home gcc, you're drunk | 20:41 |
| stekern | haha | 20:41 |
| blueCmd | I made the got insn want a "explicitly non-TLS" symbol (that makes sense I think) and then it just barfs | 20:42 |
| stekern | or1ksim booting... | 20:43 |
| stekern | I've installed ssh, so the boot is even slower now | 20:43 |
| blueCmd | hah | 20:43 |
| blueCmd | it's worth it though | 20:43 |
| blueCmd | the console isn't really useable in or1ksim | 20:43 |
| stekern | it segfaults like a boss | 20:49 |
| blueCmd | really? that's interesting | 20:54 |
| olofk | Limb: How do you connect to the bscan device? OpenOCD? | 20:55 |
| stekern | at the exact same place, with r10 = 0 | 20:55 |
| olofk | And great work with binutils everyone! | 20:55 |
| blueCmd | olofk: wouldn't have happened without you | 20:56 |
| olofk | I'm apparently better at kicking people's asses than writing code :) | 20:57 |
| olofk | Oh god! Don't tell me I'm destined to become a project manager :( | 20:57 |
| blueCmd | haha | 20:58 |
| stekern | =) | 20:58 |
| blueCmd | https://www.youtube.com/watch?v=21OwTUEiGGM that was a fun one! | 21:23 |
| blueCmd | so I got all the gcc TLS tests to work | 21:38 |
| blueCmd | that's nice I guess | 21:38 |
| blueCmd | stekern: do we support linking PIC code with non-PIC code? if I have two .o and one is fPIC and the other isn't | 21:39 |
| stekern | I don't think that work | 21:44 |
| stekern | hmm kregs->gpr[7] = 0 | 21:46 |
| blueCmd | stekern: or1k-glibc/ports/sysdeps/unix/sysv/linux/or1k/nptl/or1k_clone.S is the file where the userspace part is | 22:08 |
| blueCmd | and or1k-glibc/ports/sysdeps/unix/sysv/linux/or1k/clone.c | 22:09 |
| Limb | olofk: OpenOCD yep | 22:57 |
| blueCmd | stekern: so the last 19 errors seems to be because there are IE relocations in the tests' .o files, but GD relocations in some files that they try to link with. I have no idea why mpfr would use -fPIC for one and not the other though | 23:26 |
| blueCmd | I explicitly don't process the same symbol twice in binutils, maybe I need to hack around that | 23:26 |
| --- Log closed Wed Apr 23 00:00:17 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
