| --- Log opened Thu Aug 07 00:00:53 2014 | ||
| poke53282 | stekern: At the moment, not even a simple hello world program compiled with g++ works. gcc is fine. | 01:01 |
|---|---|---|
| poke53282 | Can you test this? | 01:01 |
| poke53282 | http://pastie.org/9451777 | 01:04 |
| stekern | poke53282: interesting. admittedly, I haven't really tested c++ much | 02:41 |
| poke53282 | more than one year in this chatroom and I still haven't figured out when stekern sleeps. | 02:45 |
| stekern | at night, mostly ;) | 02:52 |
| poke53282 | yes, every half year you switch between the artic and antarctic region. | 02:53 |
| poke53282 | That, you have never night | 02:54 |
| stekern | yeah, that might be confusing ;) | 02:58 |
| stekern | I think I have a hunch what this failure might be, it fails with an unaligned access in do_relocs | 02:59 |
| poke53282 | so it is reproducible? | 03:00 |
| stekern | yes | 03:00 |
| poke53282 | Hmm, jor1k automatically stops when there is an unaligned access. One second | 03:01 |
| stekern | we have this in glibc (and uclibc too for that matter): https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/or1k/dl-machine.h#L236 | 03:01 |
| poke53282 | Oh yes, there is an unaligned access, | 03:02 |
| poke53282 | Sorry, have to go, Back in 1 hour. | 03:04 |
| stekern | so, I guess, something like that have to be added in the REL_SYMBOLIC case here: http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n331 | 03:07 |
| poke53282 | re | 04:24 |
| --- Log closed Thu Aug 07 04:30:22 2014 | ||
| --- Log opened Thu Aug 07 04:30:35 2014 | ||
| -!- Irssi: #openrisc: Total of 35 nicks [0 ops, 0 halfops, 0 voices, 35 normal] | 04:30 | |
| -!- Irssi: Join to #openrisc was synced in 25 secs | 04:30 | |
| -!- Netsplit *.net <-> *.split quits: simoncook, juliusb, blueCmd, zama, olofk | 04:35 | |
| poke53282 | Hmm, the unaligned space is at PC: 0x30024C40, but I cannot find anything mapped there libstdc++ is mapped there, but the code begins at 0x48a18 | 05:13 |
| poke53282 | s/unaligned space/unaligned access/ | 05:14 |
| stekern | poke53282: I told you that it's in do_reloc() in libc | 05:26 |
| stekern | the address you want to search for in libc.so is 0x24C40 | 05:27 |
| stekern | (well, you're probably sane for not trusting me blindly ;)) | 05:32 |
| poke53282 | patched, let's see. | 05:39 |
| stekern | what does the patch look like? | 05:42 |
| stekern | http://pastie.org/9452070 <- a nifty script I've found to do pastie.org pastes | 05:47 |
| poke53282 | http://pastie.org/9452074 | 05:47 |
| poke53282 | quick'n dirty | 05:47 |
| stekern | so you can do: git diff | pastie -l diff | 05:49 |
| poke53282 | sounds good. | 05:49 |
| mor1kx | [mor1kx] skristiansson pushed 4 new commits to master: https://github.com/openrisc/mor1kx/compare/94d1a0bb1786...b76b3440c7dd | 05:56 |
| mor1kx | mor1kx/master 5ae50dc Stefan Kristiansson: cappuccino/decode: make branch indicate signal more lightweigth... | 05:56 |
| mor1kx | mor1kx/master 7ae5778 Stefan Kristiansson: cappuccino: move overflow disable to execute_alu... | 05:56 |
| mor1kx | mor1kx/master 5a2a7cf Stefan Kristiansson: make carry flag optional with FEATURE_CARRY_FLAG... | 05:56 |
| olofk_ | ok, so the CVC simulator doesn't like using $clog2 in parameter definitions | 05:56 |
| olofk_ | My bad for using these bleeding edge features from 2005 | 06:05 |
| poke53282 | Nope, that would have been too easy. Looks like I have to change all relocs in the switch statement. | 06:08 |
| poke53282 | Too late for today. | 06:09 |
| stekern | hmm, but it's only R_OR1K_32 that get special treatment in glibc/uclibc | 06:10 |
| stekern | I can take a look later in the evening too | 06:11 |
| poke53282 | I will figure out the correct code line tomorrow. It must be one before the memcpy (case REL_COPY:) if I remember correctly the disasm code. | 06:13 |
| stekern | R_OR1K_32 should map into REL_SYMBOLIC | 06:15 |
| stekern | http://git.musl-libc.org/cgit/musl/tree/arch/or1k/reloc.h#n13 | 06:15 |
| poke53282 | do I have to recompile only musl? | 06:21 |
| stekern | yes, that should be enough | 06:25 |
| stekern | wow, ISE is really inconsistent when it comes to timing results... | 09:54 |
| stekern | I get fluctations at over 10% fmax with non-functional changes to the source (like commenting out a piece of code versus disabling the code with a parameter) | 09:55 |
| ysionneau | are you using the same random seed ? | 09:56 |
| stekern | ...which I guess will change the seed | 09:56 |
| stekern | regardless, it's a huge difference... | 09:57 |
| ysionneau | yep :/ | 09:58 |
| ysionneau | try to fix the seed to kick this "variable" out of the equation | 09:59 |
| stekern | quartus fluctates perhaps 1%... | 09:59 |
| ysionneau | some seeds lead to design not meeting timing | 09:59 |
| stekern | yeah, I know all that... but I didn't expect fluctaitions to be > 10% | 10:00 |
| ysionneau | I guess you have a very bad local optimum in the PAR algorithm for your design :x | 10:01 |
| stekern | either way, the latest changes to mor1kx improves fmax from ~85MHz to 100MHz with MMU disabled, and from ~75MHz to 85MHz with MMU enabled when building for de0 nano | 10:22 |
| stekern | for ISE *shrugs*, it's just too inconsistent to say if there are any improvements at all... | 10:22 |
| Stman | o/ ysionneau | 10:22 |
| stekern | the changes *does* remove critical paths, so there should be improvements overall there too... | 10:24 |
| stekern | do | 10:24 |
| mafm | blueCmd_: with the patch including NO_GETCONTEXT: http://wannabuild.cmd.nu/fetch.php?pkg=libgc&arch=or1k&ver=1%3A7.2d-6.3&stamp=1407386212 | 10:39 |
| ysionneau | stekern: great :) | 10:46 |
| rah | http://makezine.com/2014/08/06/parallaxs-propeller-1-silicon-goes-open-source/ | 10:47 |
| ysionneau | yep, good news :) | 10:47 |
| ysionneau | multi core uC, open source | 10:47 |
| stekern | I agree, it's cool news that they have released their sources | 10:58 |
| blueCmd_ | mafm: cool! great | 11:06 |
| stekern | sb0: if you have a spare moment, can you give mor1kx git HEAD a build spin for your kintex7 board? | 11:24 |
| stekern | there *should* be improvements timing wise, but I'd be interested in seeing if the odd path you showed earlier still pops out | 11:25 |
| sb0 | I can't use the board right now, but I can run synthesis | 11:26 |
| stekern | yeah, that's sufficient ;) | 11:26 |
| sb0 | so gcc/llvm don't use the carry flag at all? | 11:26 |
| stekern | no, unless you enable the addc instructions | 11:26 |
| sb0 | how do you enable them, and what happens then? | 11:27 |
| stekern | there's a new parameter FEATURE_CARRY_FLAG that you should set to "NONE" in your test too | 11:27 |
| sb0 | should I try 200MHz? | 11:27 |
| stekern | yes, try the same test as when you got 200MHz for lm32 and 150 for mor1kx | 11:27 |
| sb0 | alright | 11:28 |
| stekern | you can of course try without that new parameter too if it's not too much trouble ;) | 11:28 |
| sb0 | I already have: p_FEATURE_ADDC="NONE" | 11:28 |
| sb0 | I should *also* have p_FEATURE_CARRY_FLAG="NONE"? | 11:29 |
| stekern | yes | 11:29 |
| stekern | the first removes the addc instruction, the latter removes the whole SR[CY] flag all together | 11:30 |
| stekern | seems like I remembered wrong, gcc/llvm doesn't have an option to enable addc generation. | 11:32 |
| stekern | I *think* that those italian guys added that as an option to their LLVM changes though | 11:33 |
| sb0 | does it really bring a benefit? | 11:33 |
| stekern | to enable addc generation in the compiler? | 11:35 |
| sb0 | yes | 11:39 |
| sb0 | well, addc in general | 11:39 |
| mafm | blueCmd_: but most tests are failing anyway | 11:39 |
| stekern | not sure, I guess for 64-bit arithmetic there are some advantage | 11:40 |
| sb0 | stekern, nope. http://pastebin.com/s5nSyt4r | 11:45 |
| stekern | ok, that path makes more sense than the last one at least. was there any improvements in fmax though? | 11:48 |
| blueCmd_ | mafm: yes, because of qemu-userspace | 11:48 |
| blueCmd_ | mafm: qemu-system will leave maybe 1 failing test | 11:49 |
| blueCmd_ | hopefully 0 | 11:49 |
| stekern | it's funny, using the PIPELINED multiplier has no effect on the timing at all on cyclone iv | 11:51 |
| stekern | on spartan 6, it makes a huge difference | 11:52 |
| sb0 | no, it actually became slightly worse. 157->151MHz | 11:52 |
| stekern | haha... | 11:52 |
| stekern | another thing that is funny is that I'm getting better fmax on both them simplesoc and the mixxeo soc with mor1kx than lm32... | 11:54 |
| stekern | s/them/the | 11:55 |
| sb0 | by how much? | 11:56 |
| stekern | it's mariginal. on simplesoc I think I had 88 MHz for mor1kx and 83 for lm32 when I tried with a 90MHz clock | 11:57 |
| stekern | but the path where you get the failure in mor1kx, there have to be a similar path in lm32... | 11:59 |
| stekern | it's just the cache hit check | 12:00 |
| stekern | so it can't just be that individual path that is terrible in mor1kx | 12:00 |
| rah | http://www.jobs.cam.ac.uk/job/4665/ | 12:49 |
| rah | pfft | 12:49 |
| rah | "They will work towards the tape-out of a prototype test-chip scheduled for 2015" | 12:49 |
| sb0 | yet another open arch. neither lm32, mor1kx and leon are great, and what do people do? start yet another one. | 14:03 |
| sb0 | instead of e.g. improving sw support for lm32, or debloating mor1kx or leon | 14:03 |
| sb0 | likely, their sw support will suck too | 14:04 |
| sb0 | and raspberry pi and aspect capital are fishy | 14:05 |
| sb0 | "Build your own RISC-V Computer with a Zybo or ZedBoard" | 14:08 |
| sb0 | LOL | 14:08 |
| sb0 | http://riscv.org/getting-started.html#fpga | 14:08 |
| sb0 | "Let's throw Zynq in there for academic cred and hype" | 14:09 |
| sb0 | eeerk. I'm glad I'm mostly not in academia and don't have a corporate job either. | 14:10 |
| rah | yeah | 14:38 |
| rah | stupid academics | 14:38 |
| rah | I never wanted a job with them anyway | 14:38 |
| mafm | blueCmd_: any estimation on when will qemu-system ready? | 15:25 |
| blueCmd_ | mafm: nope | 15:39 |
| blueCmd_ | sorry | 15:39 |
| blueCmd_ | I need to spent time debugging glibc, and find out why things lock up | 15:40 |
| mafm | ok | 15:44 |
| rah | https://github.com/asicguy/gplgpu | 15:57 |
| rah | http://gplgpu.com/?p=88 | 15:57 |
| rah | anyone seen this? | 15:57 |
| ysionneau | the github project, yes | 15:57 |
| rah | it's the "Silicon Spectrum" core that they wanted $$$ to release before: | 16:06 |
| rah | https://www.kickstarter.com/projects/725991125/open-source-graphics-processor-gpu/posts | 16:06 |
| rah | they tried to get some money, failed, and released it anyway :-) | 16:08 |
| rah | (originally Number Nine) | 16:10 |
| ysionneau | cool outcome | 16:10 |
| ysionneau | not for them but for the public | 16:10 |
| rah | aye | 16:11 |
| poke53282 | stekern: I like your pastie script. http://pastie.org/9453477 | 16:20 |
| poke53282 | Still doesn't work. But the alignment issue is gone | 16:20 |
| poke53282 | what is missing is a git apply with the pastie script something like "git apply < pastie http://pastie.org/9453477" | 16:31 |
| poke53282 | Yes, I know, I can use wget or curl for this. | 16:35 |
| poke53282 | "or1k-linux-musl-g++ -static-libstdc++ hello.c" works | 16:46 |
| poke53282 | according to ldd it is still loaded as a shared library. But probably not linked anymore. Another bug. | 16:48 |
| stekern | poke53282: how doesn't it work? | 17:23 |
| poke53282 | stops, no output and I have to press CTRL+C. | 17:24 |
| poke53282 | is there an easy musl debug option which I can activate? | 17:24 |
| stekern | oh, the best kind of 'not work'... | 17:25 |
| poke53282 | uclibc had something like this. | 17:25 |
| stekern | you mean something like LD_DEBUG? | 17:26 |
| stekern | afaik there's no support for that in musl | 17:26 |
| stekern | but you can of course just add the printfs yourself | 17:26 |
| poke53282 | yes, something like this | 17:27 |
| stekern | is it the hello world that still fail? | 17:30 |
| poke53282 | yes | 17:31 |
| poke53282 | if I exchange libstdc++ with a dummy it works too with -static-libstdc++. So the link is indeed not necessary | 17:31 |
| poke53282 | I can give you the output of readelf, objdump,nm,... with and without -static-libstdc++. | 17:33 |
| jeremybennett | Y'all might be interested in this EE Times post about RISC-V http://www.eetimes.com/author.asp?section_id=36&doc_id=1323406 | 17:33 |
| poke53282 | I use qemu-user by the way. And here an unaligned access should not matter. | 17:33 |
| jeremybennett | Notwithstanding my comments on the article, should we be thinking about RISC-V as the basis of OpenRISC 2000? | 17:34 |
| stekern | poke53282: I can check things on my side in an hour or two | 17:35 |
| poke53282 | wait, if I compile *without* -static-libstdc++ and *exchange* libstdc++ with a dummy it works too. | 17:39 |
| poke53282 | so, g++ links without reason. | 17:41 |
| poke53282 | https://github.com/sabotage-linux/sabotage/blob/master/pkg/gcc474 | 17:42 |
| poke53282 | Hmm, maybe we should take a closer look on those patches | 17:42 |
| stekern | hmm, looks like we still haven't seen an end to this libgcc saga... | 18:33 |
| poke53282 | So far, I haven't compiled the native gcc. I used the libstdc++ libraries from the toolchain. Maybe this is the problem. | 18:57 |
| poke53282 | Nope, still not working | 19:13 |
| stekern | no, there's some problem with libgcc.so still | 20:17 |
| stekern | hmm, or then not... I can load it with my old libc.so, but not the one I just built from git | 20:20 |
| dalias | what failures do you have with different libc.so? | 20:21 |
| stekern | with the latter I get 'Error loading shared library libgcc_s.so.1: Exec format error (needed by ./umodsi)' | 20:22 |
| dalias | what's the last syscall (strace) before that ? | 20:28 |
| stekern | http://pastie.org/9453926 | 20:33 |
| dalias | stekern, it looks to me like your libgcc_s.so.1 is all zeros.... | 20:45 |
| stekern | yeah, but it's not for real :/ | 20:48 |
| stekern | oh... wait a sec... | 20:50 |
| stekern | dalias: yup, I've got my rootfs on a initramfs and it had grown to big | 20:52 |
| stekern | and the difference between the old and new libc was size, 1.1M vs 2.8M | 20:52 |
| dalias | -g vs no -g ? | 20:54 |
| stekern | no idea why they differ that much, one was built with musl-cross and the other 'by hand' | 20:55 |
| fnunes | I'm not at the lab right now so I cannot test anything, but any ideias are apreciated.Hi there. I'm trying to connect OpenOCD to a FT4232H minimodule to a OpenRISC on a Digilent Atlys board. So far I have it connected but the output I got is this: http://pastie.org/9453945; verbose: http://paste.ubuntu.com/7982792/ . | 20:56 |
| fnunes | The first sentence was suposed to apear at the end. Sorry for that. | 20:56 |
| stekern | poke53282: the dynlinked cpp hello world works here | 21:00 |
| stekern | dalias: did you see the discussion about misaligned relocations btw? | 21:01 |
| dalias | no | 21:02 |
| dalias | what were they arising from? | 21:03 |
| stekern | I don't have details exactly where they are, but we've had the same issue in uclibc and glibc (and other archs that can't handle unaligned accesses have had similar issues). | 21:05 |
| stekern | https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/or1k/dl-machine.h#L236 | 21:06 |
| stekern | that's how we handle it in uclibc and glibc, but iirc that is just copy-pasted from something Mike Frysinger did | 21:07 |
| dalias | unaligned relocs should not arise | 21:07 |
| dalias | if they really do, they need to be handled, but i think it's more likely these are textrels or something | 21:08 |
| stekern | I'll take a deeper look if they actually belong there | 21:09 |
| dalias | relocations should only be applied to the GOT or to pointer objects in .data | 21:10 |
| dalias | and both of those are aligned | 21:10 |
| stekern | I found the patch from Mike Frysinger at least: https://sourceware.org/ml/libc-ports/2012-08/msg00098.html | 21:12 |
| stekern | ah, right, this makes me remember. https://bugs.gentoo.org/show_bug.cgi?id=394237 | 21:13 |
| stekern | it's that symbol: __gxx_personality_v0 | 21:13 |
| poke53282 | dalias: This is my current patch. But we need it only for one relocation type according to stekern: http://pastie.org/9453477 | 21:30 |
| poke53282 | stekern. Hmm, that's strange. | 21:30 |
| poke53282 | just "g++ hello.c" ? | 21:31 |
| poke53282 | and the libstdc++ is in /usr/lib ? | 21:31 |
| stekern | it's in /lib/ | 21:31 |
| poke53282 | what does ldd say? | 21:31 |
| stekern | and yes: or1k-linux-musl-g++ hello.c -o hello | 21:32 |
| poke53282 | you have to symlink libc.so to /usr/bin/ldd | 21:32 |
| dalias | how does this relocation arise? | 21:34 |
| dalias | i still think it's a bug. misaligned pointers should never exist | 21:34 |
| stekern | dalias: not sure, it's in .eh_frame | 21:35 |
| dalias | weird | 21:37 |
| dalias | i don't see where the reference to it comes from.... | 21:38 |
| stekern | looking at those bug reports, seems that both arm and mips have had similar problems | 21:38 |
| stekern | but in my arm libstdc++ I only see this: | 21:47 |
| stekern | f9ca8: R_ARM_JUMP_SLOT __gxx_personality_v0 | 21:47 |
| olofk_ | stekern: Earlier today when I was standing naked under the how water and smearing soap on my body I came to think of the critical path in mor1kx | 21:48 |
| olofk_ | I'm wondering if it's a problems with control sets | 21:48 |
| stekern | olofk_: wtf ;) | 21:48 |
| olofk_ | Yeah, I got issues | 21:48 |
| stekern | it's comforting, then my own doesn't seem so severe =) | 21:48 |
| stekern | yeah, I've had similar thoughts (although fully dressed) | 21:51 |
| olofk_ | As the issues seem to be varying between FPGA vendors and families, it could be that ISE in this case fails to map big logical expressions into one LUT | 21:51 |
| olofk_ | Eeew... Showering with your clothes on? Weird | 21:51 |
| olofk_ | Oh well. Time to go comatose for a few hours, hallucinate vividly, and then maybe suffer amnesia about the whole experience | 21:53 |
| stekern | or into a slice, comparing the reg/lut ratio between lm32 and mor1kx, lm32 has about 1/1 while mor1kx 1/2 | 21:54 |
| olofk_ | Yeah, that might be an indication. I know that Xilinx devices prefer sync reset for example. What's the default for mor1kx? | 21:55 |
| stekern | sync reset | 21:55 |
| olofk_ | ah ok | 21:56 |
| olofk_ | I'm interested in firing up the good ol' fpga_editor and take a look when I got time | 21:57 |
| olofk_ | Best tool ever! Has saved a few last minute releases for large projects I've been working on :) | 21:57 |
| poke53282 | stekern, can you send me your hello binary? | 21:57 |
| stekern | poke53282: http://oompa.chokladfabriken.org/openrisc/cpptest | 22:01 |
| poke53282 | http://pastie.org/9454093 | 22:06 |
| poke53282 | something is really messed up here. | 22:06 |
| dalias | stekern, is .eh_frame even writable? | 22:06 |
| poke53282 | sorry, stekern. My fault. The busybox wget gave me a zero byte cpptest. | 22:10 |
| poke53282 | Ok, so same problem with cpp test. | 22:11 |
| poke53282 | Next request. Please provide me your libstdc++xxxx.so | 22:11 |
| dalias | i want an explanation from the gcc side | 23:29 |
| dalias | based on this thread: | 23:30 |
| dalias | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 | 23:30 |
| dalias | they claim the misaligned reloc is valid | 23:30 |
| dalias | at least on arm | 23:30 |
| dalias | but the PDF file they cite says that R_ARM_ABS32 is not even valid as a dynamic reloc; it's a static relocation | 23:30 |
| dalias | anyway, it seems ABS32 has become a de facto dynamic reloc, but the part of the spec about allowing misalignment is for static linking (where misaligned relocs are basically always supported) | 23:33 |
| dalias | anyway, i want to know what kind of craziness the misaligned reloc is coming from | 23:33 |
| --- Log closed Fri Aug 08 00:00:55 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!