| --- Log opened Sun Jan 18 00:00:00 2015 | ||
| dalias | if you use gentoo, you spend more time upgrading it than using it :) | 00:50 |
|---|---|---|
| dalias | or at least that was how it looked when my officemate used to use gentoo | 00:51 |
| dalias | he was always sitting around waiting for it to compile | 00:51 |
| dalias | :) | 00:51 |
| stekern | olofk: why aren't you using your zenbook? | 06:05 |
| olofk | stekern: It's in another room :) | 06:24 |
| olofk | dalias: Yeah, I can't argue with that. It's very irritating when you just quickly want to try something out | 06:25 |
| stekern | ;) | 06:26 |
| dalias | :) | 06:31 |
| olofk | stekern: Have you found any bugs from the fixed regression tests? | 06:52 |
| olofk | Or has it all been issues with the test cases themselves? | 07:03 |
| stekern | https://github.com/openrisc/or1k-gcc/commit/50e11f73098c722676829ae73caf09246e81cd44 | 07:07 |
| stekern | that is the only "generic" gcc bug | 07:08 |
| stekern | animation on window minimize/restore must be the silliest "eye candy" there is | 07:14 |
| olofk | Yeah, I tink we can blame that on Apple. I remember when Mac OS X was new and all Mac owners proudly showed off their windows animations | 07:19 |
| olofk | IIRC there was even a button you could hold down to make the animations run in slow motion. I'm pretty sure that was only to let the Mac people show off | 07:21 |
| olofk | Of course Compiz raised the bars with wobbly windows that was the default setting on Ubuntu for a while | 07:21 |
| olofk | stekern: What target are you running against? or1ksim, FPGA, jor1k, qemu? | 07:29 |
| stekern | or1ksim | 07:29 |
| -!- FreezingAlt is now known as FreezingCold | 07:41 | |
| stekern | bah, one of the fails was because I had screwed up a merge conflict | 07:47 |
| stekern | ..in that test file | 07:48 |
| olofk | dalias: I liked your article on threads. It also once again reminded me to never design a C library :) | 09:06 |
| olofk | stekern: If they decide to do a newlib 2.2.1 with proper OpenRISC support I would like to do a snapshot release of GCC, so that we can at least build an or1k-elf toolchain (without gdb) without relying on anything from git. Whaddayathink? | 09:08 |
| olofk | Just discovered that we have automated builds of the or1k-elf toolchain. Thanks wallento :) | 09:13 |
| olofk | I see that 64-bit or1ksim is in the works. That means we just need 64-bit binutils, gcc, C libraries, Linux, bootloaders, RTL implementations and wishbone infrastructure | 12:25 |
| stekern | piece of a cake | 12:31 |
| stekern | but a reference sim is imo the right first step | 12:32 |
| olofk | Sure. That or a cgen model I guess | 12:32 |
| olofk | Both make sense, because then you can verify them against each other | 12:34 |
| * stekern nods in agreement | 13:11 | |
| olofk | How are 64 bit arguments passed to functions? | 13:30 |
| olofk | Looking at bug 103 | 13:30 |
| olofk | I guess varargs is involved if that makes any difference | 13:33 |
| stekern | varargs are passed on the stack | 13:41 |
| olofk | And r1 points to the stack? | 13:46 |
| poke53282 | yes | 13:49 |
| olofk | I'm looking at the asm of the code in bug 103 | 13:51 |
| olofk | http://pastie.org/9838253 | 13:51 |
| olofk | It looks like r3 is set up before the call to printf, but why, if it only cares about r1? | 13:52 |
| stekern | the format arg of printf is not a vararg | 13:54 |
| olofk | ah right. there can be other args before a vararg | 13:55 |
| olofk | Get it now | 13:55 |
| olofk | Well, my only conclusion is that the correct value is being passed to printf. | 13:56 |
| poke53282 | were is the description of bug 103? | 13:56 |
| olofk | http://bugzilla.opencores.org/bugzilla4/show_bug.cgi?id=103 | 13:56 |
| stekern | yes, that bug is newlib specific | 13:57 |
| olofk | Sounds like a quite severe bug to me | 13:58 |
| olofk | greping for printf in the source code of a C library.... worst idea ever | 14:00 |
| poke53282 | Yes, I can confirm, that musl libc behaves correctly. | 14:02 |
| olofk | ok, so the error is probably inside this 1129 line C function that gets translated to 2098 lines of ASM | 14:54 |
| olofk | I'm not sure if my usual approach of using printfs to debug will work here :) | 15:08 |
| olofk | If I recompile newlib, do I have to compile gcc again as well, or can I get it to pick up my new libc somehow? | 15:11 |
| poke53282 | If you just change the printf function, you don't have to compile gcc again. | 15:13 |
| olofk | Cool. | 15:42 |
| olofk | Hmm... can I put in l.nop's with different immediate values to figure out where I am, or will those be removed? | 15:44 |
| olofk | -O0 will keep them I guess, but can I keep them with -O2? | 15:44 |
| poke53282 | not sure about the nop's | 15:46 |
| poke53282 | but you can add some puts debug message in the code. | 15:47 |
| olofk | Isn't puts in stdio as well? | 15:48 |
| olofk | What I mean is that I'm not sure puts is available for me to use here | 15:49 |
| poke53282 | yes puts is in stdio | 15:49 |
| poke53282 | but it doesn't call printf. And I guess you want to put some nops in the printf function. | 15:50 |
| poke53282 | But I don't understand, what the real problem is. You compile a shared or static libc library I guess. | 15:51 |
| olofk | Well, it's in a function called by printf, but I see that stdio.h is included so I should be ok | 15:51 |
| olofk | I guess it's a static one, since it's the bare-metal toolchain | 15:52 |
| poke53282 | never used newlib. | 15:53 |
| stekern | olofk: gcc won't touch the asms if you make them __asm__ __volatile__ | 15:59 |
| mor1kx | [mor1kx] bandvig pushed 1 new commit to withfpu: https://github.com/openrisc/mor1kx/commit/213d7b28e6cd5fa9179368b371669400034c183a | 17:10 |
| mor1kx | mor1kx/withfpu 213d7b2 Andrey Bacherov: 1) Remove support of FPU ported from OR-1200 project... | 17:10 |
| stekern | hmmpf, I had screwed up my musl toolchain install, so I had an old musl version in there... | 18:11 |
| olofk | stekern: Cool. I'll try that volatile thingie | 19:01 |
| poke53282 | stekern: For this kind of work I think the snapshot functionality of btrfs would be nice. | 19:11 |
| stekern | I'm not familiar with that, what does it do? | 19:14 |
| poke53282 | freezes the current state of the filesystem and you can revert it whenever you want. | 19:38 |
| poke53282 | I guess, you can do it with directories. | 19:38 |
| poke53282 | So, when you have a working musl version, you can make a snapshot of this directory. | 19:39 |
| poke53282 | This feature doesn't need any additional resources. | 19:40 |
| olofk | poke53282: There's also "ln -s", "cp -r" and "rm -rf" that can be used for this :) | 19:53 |
| olofk | stekern: You got a defconfig for Atlys? Phy is detected but it's not booting anymore | 19:57 |
| poke53282 | yes, but btrfs does this immediately. no waiting time | 20:03 |
| olofk | hmmm... kernel isn't booting in or1ksim either | 20:07 |
| olofk | Crap. If I only had some way to recover my previous .config ... :) | 20:08 |
| olofk | Comparing to a working boot, it seems like the boot console is disabled, but ttyS0 is never enabled. Any ideas? | 20:13 |
| stekern | I don't think I do | 20:25 |
| stekern | what did you change to brake the config? | 20:26 |
| olofk | I enabled ethernet and ethoc, and then tried to disable all the other stuff that was automatically enabled | 20:27 |
| olofk | But an interesting thing is that I got several new questions when I ran make afterwards | 20:28 |
| olofk | Like some basic OpenRISC-related questions. Can't recall exactly what it was now | 20:28 |
| olofk | Aha! I had saved a working config | 20:45 |
| olofk | Yes! Phy found and kernel booting | 20:51 |
| olofk | Time to enable TCP/IP for some real networking | 20:54 |
| olofk | Fucking hell! ifconfig works | 20:55 |
| --- Log closed Mon Jan 19 00:00:03 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!