| --- Log opened Mon Apr 21 00:00:14 2014 | ||
| stekern | olofk: no, but it is in the 30 day eval version | 04:25 |
|---|---|---|
| stekern | use diila instead | 04:25 |
| stekern | github.com/skristiansson/diila | 04:26 |
| blueCmd | stekern: while scouring the internet somebody mentioned that you have to emit_ stuff in a certain stage for it to work correctly, could that be i? | 08:28 |
| blueCmd | it* | 08:28 |
| stekern | blueCmd: yeah, that's what I had in mind | 09:25 |
| rfajardo | hello everyone. Happy Easter! I’m having problems with uClibc from Jonas. When I try to set the defconfig, it fails. I have an older uClibc which works. Do you guys know anything about it? | 11:48 |
| blueCmd | "fails" is a bit ambigious | 11:51 |
| blueCmd | also, hi! | 11:51 |
| stekern | rfajardo: if you are using the or1k- toolchain, you should use this: https://github.com/openrisc/uClibc-or1k | 12:25 |
| rfajardo | Can't find default configuration "extra/Configs/defconfigs/ARCH"! | 12:25 |
| rfajardo | stekern, I’m actually trying to build or32 | 12:26 |
| rfajardo | grep tells me it comes from .//extra/config/conf.c | 12:26 |
| stekern | then I don't know what's wrong, jonas tree hasn't changed in two years and it has definetely worked after that | 12:26 |
| rfajardo | funny enough, uClibc-or1k works | 12:27 |
| rfajardo | I’m sorry I might have sounded bad there. I’m only boggled | 12:27 |
| stekern | nah, I don't think you did | 12:28 |
| rfajardo | the explanation of two trees shed some light on it | 12:28 |
| stekern | I'm starting to understand why they are calling libreoffice a killer-app, it's f*cking killing me... | 12:37 |
| rfajardo | Ihahahaha | 12:40 |
| blueCmd | stekern: idea: implement TLS resolve in legitimize_address instead of the expansion of the move operation | 12:57 |
| blueCmd | I took a closer look, and it appears that that seems to be the way other arches has done it | 12:57 |
| blueCmd | This dead doc patch seems to point towards that aswell: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01070.html | 12:58 |
| rfajardo | stekern, I was able to patch the Makefile.in in order to make it work. OS X problem most probably. I’m still wasting my time on that :). | 13:12 |
| stekern | blueCmd: sgtm | 14:16 |
| blueCmd | stekern: with legitimize: http://01c5901e177c4085.paste.se/ | 15:52 |
| blueCmd | it loads the tls offsets higher up in the function, but it's still not correct | 16:02 |
| blueCmd | stekern: I'm wondering if I or1k_save_reg or something is not taking this into account. | 17:03 |
| blueCmd | I added a fprintf right before the call to mpfr_cache. The arguments to fprintf are constructed the correct way | 17:05 |
| blueCmd | fprintf obviously doesn't take the same first argument as mpfr_cache, and without the TLS variable GCC sees that and saves/restores r3 around the fprint call | 17:06 |
| blueCmd | with TLS GCC forgets that | 17:06 |
| stekern | hmm, how does your or1k.c look like now? | 17:07 |
| stekern | or1k_save_reg shouldn't be involved, since the problem is with caller-saved regs | 17:08 |
| olofk | Aha. I didn't know you could have a wiki connected to a github repo. | 17:41 |
| olofk | I can't understand how github can make enough money to support all these services | 17:41 |
| blueCmd | stekern: http://storage.googleapis.com/bluecmd-openrisc/or1k.diff | 17:44 |
| blueCmd | beware of the crap | 17:45 |
| blueCmd | output from gcc: http://6b8256f743158584.paste.se/ | 17:45 |
| blueCmd | or1k_legitimize_address doesn't call the TLS specific function, which I think is kind of odd, so the result should have been the same as before | 17:46 |
| blueCmd | i implemented TARGET_CANNOT_FORCE_CONST_MEM as well now, no change | 18:05 |
| olofk | stekern: Yes, I'm going for the diila solution. Problem is that have to get the stupid debug interface working first | 18:06 |
| olofk | Limb: You had some success with the bscan component for you Artix, right? | 18:09 |
| stekern | olofk: I think there are quite a few companies that actually use github for "private repos" | 18:14 |
| stekern | ...and those aren't free | 18:15 |
| blueCmd | olofk: I pay for github :) | 18:15 |
| stekern | blueCmd: ok, yeah, that looks like what other archs are doing afaics | 18:18 |
| olofk | I know that they have a commercial alternative. Just didn't know anyone who used that | 18:19 |
| olofk | blueCmd: Is it private or via your company? | 18:19 |
| blueCmd | olofk: privately | 18:24 |
| -!- Megaf_ is now known as Megaf | 18:27 | |
| stekern | blueCmd: there's got to be some deep gcc thing that goes wrong there | 18:33 |
| stekern | would be interesting to see how the asm output for e.g. mixcoblaze looks like for the same thing | 18:33 |
| stekern | microblaze too... | 18:34 |
| stekern | with the same gcc I mean | 18:34 |
| stekern | blueCmd: ah, I think for libcalls, you actually have to manually tell gcc about the clobbers for libcalls | 18:59 |
| stekern | ehm, minus one for libcalls | 18:59 |
| stekern | take a look at CALL_INSN_FUNCTION_USAGE | 19:02 |
| stekern | and you can look at the nios2 port for an example where it's used together with the __tls_get_addr | 19:03 |
| stekern | ...except, there emit_library_call isn't used... | 19:07 |
| stekern | and open code that function call was something you tried and failed, right? | 19:15 |
| stekern | this bugreport looks strikingly similar to our problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 | 19:28 |
| blueCmd | stekern: yeah, i tried a bunch of different ways | 19:32 |
| blueCmd | if I force the libcall to save stuff on the stack it sort of looks ok, but it might be a fluke | 19:32 |
| blueCmd | stekern: interesting bug report | 19:34 |
| stekern | you can sprinkle some debug_tree (rtx) around the libcall to get some more info what's going on internally | 19:35 |
| blueCmd | debug_tree - didn't know about that one | 19:36 |
| blueCmd | stekern: thanks for finding that bug report, I had something very close to that but it helps knowing I'm on the (hopefully) right track | 19:56 |
| stekern | my pleasure | 19:59 |
| stekern | I think I'm finally done with my libreoffice deathmatch (aka updating it with the atomic instructions) | 20:17 |
| stekern | blueCmd: http://pastie.org/9098453 <- wut, the most important package for or1k is missing!?! | 20:33 |
| blueCmd | stekern: hah | 20:36 |
| stekern | so, another question, is the libffi complete enough for glib? | 20:44 |
| blueCmd | well, it runs gtk | 20:45 |
| blueCmd | so I would say so :) | 20:45 |
| stekern | nice | 20:45 |
| blueCmd | it's quite hallow though | 20:45 |
| stekern | I want irssi | 20:45 |
| blueCmd | but it should work fine for most cases | 20:45 |
| stekern | which needs glib (and IIRC glib was the showstopper last I tried to compile it) | 20:45 |
| blueCmd | apt-get build-dep irssi was successful, I can build it if you want | 20:46 |
| blueCmd | fix gcc and I will build irssi - deal? :) | 20:46 |
| stekern | haha | 20:46 |
| blueCmd | stekern: mind taking another look what I have? I have cleaned stuff up a bit | 20:48 |
| stekern | haven't you noticed that I'm doing my best to try to help you fix gcc? ;) | 20:48 |
| stekern | not sure how much I help or just throw you of in wrong directions though =) | 20:48 |
| blueCmd | stekern: hah, I do appricate it | 20:48 |
| blueCmd | so, I did what PA did for legitimitate_constant_p: return false for TLS GD and LD | 20:49 |
| blueCmd | that makes the code stop recognizing TLS relocations at all (at least GD and LD, haven't looked at IE and others) and just default to GOT relocations | 20:49 |
| stekern | hmm, but only for constants right? | 20:51 |
| blueCmd | well, the symbol is the constant - no? | 20:52 |
| blueCmd | http://e88ae51e479a312e.paste.se/ | 20:53 |
| stekern | umm, yes I suppose... | 20:53 |
| blueCmd | that's the output | 20:53 |
| blueCmd | http://e35bb3e0464458ae.paste.se/ | 20:54 |
| stekern | http://pastie.org/9098504 <- hmm, interesting | 20:54 |
| blueCmd | hah | 20:54 |
| blueCmd | everything odd might be this TLS bug :) | 20:55 |
| blueCmd | it isn't, but I might just as well motivate myself with that thinking | 20:55 |
| stekern | you just want me to keep focused =) | 20:55 |
| stekern | could be a mor1kx bug too | 20:56 |
| stekern | but I got this: http://pastie.org/9098512 | 20:57 |
| blueCmd | ooh! | 20:57 |
| blueCmd | that's nice :) | 20:57 |
| stekern | 4 days! | 20:57 |
| blueCmd | http://gcc.gnu.org/bugzilla/attachment.cgi?id=25459 nice that the bug had a smaller test case | 21:02 |
| stekern | blueCmd: but the pa change added the thing in emit_move_sequence too | 21:02 |
| stekern | ah, that's what you are doing in expand_symbol_ref? | 21:02 |
| stekern | what I don't like about the GNU changelogs is that they only tell what is being done, not why | 21:05 |
| blueCmd | stekern: emit_move_sequence should already emit for TLS | 21:06 |
| blueCmd | but it makes sense that we should add something there as well | 21:06 |
| blueCmd | stekern: did you even try to install irssi? :) | 21:08 |
| blueCmd | stekern: I finished building it and got a error saying 'package already uploaded to repo' | 21:08 |
| stekern | haha, no | 21:08 |
| stekern | doh... | 21:09 |
| stekern | tightvncserver seems to work fine on real iron to | 21:10 |
| blueCmd | cool! | 21:11 |
| blueCmd | stekern: if you build http://a3f3f8689ba7a707.paste.se/ and run that, does it return the same number 3 times? | 21:17 |
| blueCmd | on or1k that is | 21:17 |
| blueCmd | in qemu it's totally scrambled | 21:17 |
| stekern | does it matter if I build it natively or cross-compile it? | 21:17 |
| stekern | it really feels a bit unreal to be running 'serious stuff' like this on a FPGA-devboard | 21:18 |
| stekern | and this easily | 21:19 |
| stekern | (from a user perspective I mean, there's some solid work behind from your part) | 21:19 |
| stekern | +it | 21:19 |
| stekern | everything doesn't go completely smoothly though =) http://pastie.org/9098551 | 21:20 |
| blueCmd | stekern: just run it should be fine | 21:23 |
| stekern | http://pastie.org/9098557 | 21:23 |
| blueCmd | ok, great | 21:24 |
| blueCmd | the first one not so great | 21:24 |
| blueCmd | stekern: see if you can strace irssi | 21:24 |
| blueCmd | ok. so emit_move_insn calls targetm.legitimate_constant_p with the comment: | 21:25 |
| blueCmd | 4 »· /* If the target's cannot_force_const_mem prevented the spill, | 21:25 |
| blueCmd | 5 »· assume that the target's move expanders will also take care | 21:25 |
| blueCmd | 6 »· of the non-legitimate constant. */ | 21:25 |
| blueCmd | setting cannot_force_const_mem to True for TLS related symbols makes a lot of stuff happen | 21:26 |
| blueCmd | http://787043bdaa30f2e4.paste.se/ | 21:26 |
| stekern | hmm, I guess the unspec is one of the UNSPEC_TLS* there? | 21:28 |
| blueCmd | yes | 21:30 |
| blueCmd | UNSPEC_TLSGDHI | 21:30 |
| stekern | ok... and it doesn't match movsi_tlsgdhi, because it's not and immediate anymore? | 21:32 |
| stekern | s/and/an | 21:32 |
| stekern | pa uses a "tld_symbolic_operand" predicate there | 21:34 |
| blueCmd | I don't know why it doesn't match, I'm reading http://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html atm | 21:36 |
| blueCmd | immediate_operand | 21:36 |
| blueCmd | This predicate allows any sort of constant that fits in mode. It is an appropriate choice for instructions that take operands that must be constant. | 21:36 |
| blueCmd | even chaning to 'general_operand' and '' doesn't do anything | 21:39 |
| stekern | ah, I was just about to ask what happens if you change it to "" "" | 21:39 |
| stekern | but does it ICE then too? | 21:39 |
| blueCmd | yes | 21:40 |
| blueCmd | same error | 21:40 |
| blueCmd | but where does it get the value of UNSPEC_TLSGDHI (i.e 10) ? | 21:40 |
| blueCmd | I wonder if maybe it's trying to evaluate the define_insn and fails there | 21:40 |
| blueCmd | maybe I need a define_expn | 21:40 |
| olofk | Fuck yeah! My wb_ram works on target now | 21:41 |
| olofk | I'm getting close to finishing my first board port | 21:41 |
| stekern | http://pastie.org/9098584 | 21:41 |
| stekern | ^ end of the irssi strace | 21:42 |
| blueCmd | stekern: hah, please remove or1k_atomic from your printout | 21:42 |
| blueCmd | stupid person who implemented that | 21:42 |
| blueCmd | also, do LD_DEBUG=all irssi once | 21:43 |
| blueCmd | stekern: I commented out the emit_insn (gen_movsi_tlsgdhi (dest, x)); and emit_insn (gen_movsi_tlsgdlo (dest, dest, x)); | 21:44 |
| blueCmd | ofc the code doesn't run, but the function call shows as correctly generated | 21:44 |
| blueCmd | which is pretty exciting | 21:45 |
| stekern | ok, that's progress | 21:46 |
| blueCmd | I'm wondering if the relocation tlsgdhi gets stuck in the constant_p legitimate thing | 21:46 |
| blueCmd | http://a6e394065fe64558.paste.se/ that's the current output (with the emits reenabled) | 21:47 |
| blueCmd | http://81a95059389da9f6.paste.se/ the output without it enabled | 21:47 |
| blueCmd | http://1594ab255ffd9084.paste.se/ (the same as the last one but with aligned lines) | 21:47 |
| olofk | Limb: If you're still interested in my wb_ram component you can try this one https://www.dropbox.com/s/w7dnlu5sgyx5v7j/wb_ram.tar.gz | 21:49 |
| _franck__ | stekern: would you mind pushing your ps2 core to orpsoc-cores ? | 21:49 |
| stekern | _franck__: not at all, it's due for my atlys port anyway | 21:50 |
| blueCmd | stekern: mips wraps the symbol in an 'unspec_address' | 21:50 |
| _franck__ | stekern: great I only miss ps2 and spi then my board will have full support. I might add ac97 if I have enough room, I'm 94% full right now :( | 21:53 |
| stekern | blueCmd: http://pastie.org/9098623 <- irssi strace with the or1k_atomics filtered out | 22:04 |
| blueCmd | stekern: aha! | 22:05 |
| blueCmd | stekern: you're running a kernel, right? | 22:05 |
| blueCmd | ;) | 22:05 |
| stekern | mmm, it seems like a valid assumption ;) | 22:05 |
| blueCmd | https://github.com/bluecmd/or1k-linux that kernel has all the awesome you need | 22:06 |
| blueCmd | you will lose your uptime though :( | 22:06 |
| stekern | ah, right the signal patch... | 22:07 |
| stekern | I'll just cherry-pick it from jonas master-next | 22:09 |
| stekern | I think I have all the other goodies | 22:09 |
| stekern | my uptime :( | 22:11 |
| blueCmd | you have my atomics and TLS? | 22:11 |
| stekern | yes | 22:12 |
| blueCmd | I guess you have those, otherwise you wouldn't be able to boot | 22:12 |
| stekern | don't think anything would have worked without those ;) | 22:12 |
| blueCmd | Yeah | 22:12 |
| stekern | now irssi gave me a bus error instead ;) | 22:15 |
| blueCmd | stekern: repeat! | 22:15 |
| blueCmd | for gcc, I'm close - I can feel it! (I hope :D) | 22:16 |
| blueCmd | I just need to figure out how to make the second pass of legitimate pass for the tldgd relocs | 22:16 |
| stekern | that second pass is always a b*tch | 22:17 |
| stekern | I remember I had a lot of problems with the got things with that | 22:18 |
| stekern | and in llvm, it was no troubles at all to add them... | 22:18 |
| stekern | why am I running 'grep -v or1k_atomic irssi.strace' on the board and not on my ws? | 22:19 |
| stekern | http://pastie.org/9098653 | 22:22 |
| stekern | it's the same, but killed with different sig | 22:22 |
| stekern | lemme double check my kernel build | 22:23 |
| blueCmd | I want to be able to get from my symbol X to it's "parent" to see if it's in an UNSPEC | 22:28 |
| blueCmd | I wonder if that's possible | 22:29 |
| stekern | maybe, I don't know how though (at least not from the top of my head) | 22:31 |
| stekern | now it's segfaulting again... | 22:34 |
| stekern | probably just a coincident of which address get screwed up | 22:35 |
| stekern | _franck__: https://github.com/openrisc/orpsoc-cores/commit/38c047e5e634cbcbb2b19112284a8e2cb0d31442 | 22:51 |
| blueCmd | stekern: try running wuth LD_DEBUG | 22:55 |
| --- Log closed Tue Apr 22 00:00:16 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!