| --- Log opened Sun Jan 12 00:00:50 2014 | ||
| blueCmd_ | stekern or anybody with or1ksim code knowledge. I would like a code review on a feature: http://5d7278c70c6626d7.paste.se/ | 00:42 |
|---|---|---|
| blueCmd_ | jeremybennett: So apparently gcc has added some basic parallelism in their tests, https://github.com/bluecmd/or1k-gcc/blob/master/gcc/Makefile.in#L511 | 02:07 |
| blueCmd_ | it seems to work quite nicely with small modifications. I stole some inspiration from the older scripts, and it seems to be chugging along in a nice speed now | 02:08 |
| jeremybennett | blueCmd_: Yup - that's the part of the GCC make I was referring to. To increase the parallelism you need to go for finer splitting up of check_gcc_parallelize. | 07:44 |
| olofk | _franck_: Nope. Can't run it using main() either | 07:49 |
| olofk | Where does libelf come from? Wondering if I have a strange version of that | 07:50 |
| olofk | aha... I don't _have_ libelf installed :) | 07:50 |
| olofk | shouldn't -lelf complain in that case? | 07:50 |
| olofk | hmm.. I do how elfutils however | 07:51 |
| olofk | And that has installed a libelf.a | 07:51 |
| olofk | Could that be an incompatible version of libelf perhaps | 07:52 |
| _franck_ | olofk: that might be that | 08:45 |
| _franck_ | [franck@centos ~]$ /sbin/ldconfig -p | grep libelf libelf.so.1 (libc6) => /usr/lib/libelf.so.1 libelf.so (libc6) => /usr/lib/libelf.so | 08:48 |
| _franck_ | which Linux distrib do you have ? | 08:49 |
| olofk | _franck_: gentoo | 09:06 |
| olofk | But it looks like elfutils should be a drop-in replacement for libelf | 09:07 |
| olofk | I wonder if it's a 32/64-bit problem | 09:07 |
| olofk | I'm looking for error codes from elf_getdata_rawchunk to see if I can find any more clues | 09:08 |
| _franck_ | raise RunTimeError("Error: Command " + self.cmd + " not found. Make sure it is in $PATH") | 09:13 |
| _franck_ | NameError: global name 'RunTimeError' is not defined | 09:13 |
| _franck_ | olofk: is that your new thing ? | 09:13 |
| olofk | Ah crap | 09:14 |
| olofk | That should be RuntimeError | 09:14 |
| olofk | Thought I had fixed that | 09:16 |
| _franck_ | now: AttributeError: 'exceptions.RuntimeError' object has no attribute 'value' | 09:16 |
| olofk | What the hell..? | 09:16 |
| olofk | Which line? | 09:16 |
| _franck_ | /home/franck/openrisc/orpsoc/orpsoc/provider/opencores.py", line 58, in _checkout print(e.value) | 09:16 |
| _franck_ | I didn't have subversion installed :) | 09:21 |
| _franck_ | now it works in ubuntu | 09:22 |
| _franck_ | /usr/lib/i386-linux-gnu/libelf-0.157.so | 09:22 |
| _franck_ | 0.157 here, I had /usr/lib/libelf-0.152.so on my centos | 09:23 |
| blueCmd_ | jeremybennett: ah, I see | 09:25 |
| olofk | _franck_: It was good that you didn't have subversion. You uncovered a bug :) | 09:29 |
| olofk | _franck_: Pushed a fix now | 09:31 |
| olofk | I got elfutils 0.149. Don't know how that corresponds to libelf itself | 09:32 |
| olofk | _franck_: Does you code work without modifications on both centos (0.157) and ubuntu (0.152)? | 09:34 |
| _franck_ | yes | 09:34 |
| olofk | I could try updating my libelf then and see if that helps | 09:34 |
| olofk | Or is it possible to get more info on what fails? My C skills aren't as good as they should be :/ | 09:34 |
| _franck_ | we could print the error code where it fails like you told some lines before | 09:35 |
| olofk | But where can I find the error codes? Tried man and google | 09:36 |
| _franck_ | in the source code of course :) | 09:36 |
| _franck_ | that's the openrisc development philosophy, you should know it :) | 09:37 |
| olofk | haha | 09:37 |
| blueCmd_ | code never lies | 09:39 |
| olofk | blueCmd_: Tell that to the IOCCC guys :) | 09:39 |
| _franck_ | olofk: printf("error = %d\n", errno); after the failling call | 09:39 |
| blueCmd_ | olofk: hah | 09:40 |
| _franck_ | the lib set errno: __libelf_seterrno (ELF_E_NOMEM); | 09:40 |
| blueCmd_ | if it's a system errno you can use perror, but maybe it's an internal libelf thing | 09:41 |
| olofk | errno undeclared... I guess I'm missing something obvious | 09:41 |
| _franck_ | #include <errno.h> | 09:41 |
| olofk | error = 0 | 09:42 |
| _franck_ | well, I thin k I'll install elfutils 0.149 :) or you can upgrade and we can tell autoconf to check for libelf > 0.152 :) | 09:44 |
| olofk | I'll upgrade | 09:46 |
| olofk | But what the hell is error code 0? I guess it means no error at all, right? | 09:47 |
| _franck_ | ELF_E_NOERROR = 0 | 09:48 |
| olofk | works fine with 0.152 | 10:07 |
| olofk | The problem now would be how to require a certain version of a lib | 10:08 |
| olofk | I'm already planning on using gentoo-style dependencies (like >=libelf-0.152), but it will take some time to get that implemented | 10:09 |
| olofk | Perhaps it's best just to put it in a README for now | 10:09 |
| olofk | Another way would be to abort the simulation if we detect that the ELF doesn't load correctly and print out a message that tells the user to make sure to check that libelf is >=0.152 | 10:12 |
| olofk | Fow now, I'm applying your patch together with a short README and changing phdr/shdr to size_t. Does that sound ok? | 10:17 |
| _franck_ | olofk: ok | 10:22 |
| olofk | and thanks for doing this. We no longer need to have the or1k toolchain installed to run efl simulations. That's huge improvement | 10:27 |
| blueCmd_ | stekern: I listened to your presentation about the toolchain from back in oct. I was very thrilled to hear that it should be possible to build native gcc | 10:47 |
| blueCmd_ | http://f72ac5a04b3ee835.paste.se/ - and it actually works! | 10:47 |
| -!- Netsplit *.net <-> *.split quits: stekern, poel, jeremybennett, vxe | 11:08 | |
| blueCmd_ | jeremybennett: I'm having a bit of a problem running the testsuite for or1ksim since or1k-asm.h and spr-defs.h are not included since I'm not running newlib | 14:00 |
| jeremybennett | blueCmd_: It's a long time since I ran the regression test suite. Most of it involves compiling programs and then checking they run OK on Or1ksim. | 14:03 |
| jeremybennett | So you'll need a compiler that has libc support. | 14:03 |
| jeremybennett | But the two headers you mention I don't think are to do with that. spr-defs.h is used to test that the various SPRs are accessible. | 14:04 |
| jeremybennett | I can't recall what or1k-asm.h is used for. IIRC neither is included by default in a C compilation, so somewhere there must be a flag asking for them to be included. | 14:05 |
| jeremybennett | HTH | 14:05 |
| blueCmd_ | jeremybennett: well, both of those files are in or1k-src/newlib and also in or1k-src/sim. or1ksim/cpu/or1k has spr-defs.h, but the testsuite does not look for them there | 14:56 |
| blueCmd_ | I have glibc as the toolchain, and I don't think it makes much senes to ship spr-defs.h and or1k-asm.h with glibc | 14:57 |
| stekern | blueCmd_: but doesn't the or1ksim testsuite depend on newlib? | 15:14 |
| blueCmd_ | stekern: hmm.. that would sort of make sense now when you say it | 15:14 |
| stekern | I mean, it runs baremetal programs iirc | 15:15 |
| blueCmd_ | yeah | 15:15 |
| blueCmd_ | quite a lot of pain in setting up a build environment for a gcc-newlibc for that, meh. | 15:26 |
| blueCmd_ | _franck_: are you able to execute "make check" in or1ksim ? | 15:27 |
| jeremybennett | blueCmd_: sorry for the delay | 15:58 |
| jeremybennett | I 'm not an expert on glibc, but somewhere it must have a board support package - the equivalent of libgloss in newlib. That will need to know SPR values. | 15:59 |
| jeremybennett | So there should be an equivalent of spr-defs | 15:59 |
| jeremybennett | as stekern points out the regression tests are of bare metal programs, so you need something. | 16:01 |
| jeremybennett | I don't know how much more work has been done recently, but the basic newlib implementation is pretty trivial. It only supports output to stdout, which is all you need for testing. | 16:02 |
| jeremybennett | IIRC I did the baseline implementation in an afternoon. | 16:02 |
| jeremybennett | So should be pretty easy to get up and running. | 16:02 |
| stekern | jeremybennett: since glibc isn't really targetted for baremetal, i don't think there are bsp support in it | 16:12 |
| jeremybennett | Ah - OK. I did wonder why glibc rather than eglibc. | 16:13 |
| stekern | besides, there are other problems with trying to use the linux toolchain to compile baremetal | 16:14 |
| stekern | libgcc is compiled with -fPIC | 16:14 |
| stekern | jeremybennett: from what i understood, since eglibc is derived from glibc, it's better to do the port directly in glibc and then pull the stuff from there to eglibc | 16:15 |
| stekern | that's paraphrasing blueCmd_ though, he knows better | 16:16 |
| jeremybennett | stekern: I agree - I wasn't suggesting using the Linux toolchain. Just being muddle headed in thinking someone had done a bare metal version of glibc/eglibc | 16:19 |
| blueCmd_ | yes sorry about that. I was not thinking straight | 16:38 |
| blueCmd_ | anyway yes, eglibc has glibc as upstream and they want to keep the diff between them and glibc as small as possible, which is understandable | 16:39 |
| olofk | I think I've asked this before, but would it makes sense to have something like a or1k-headers repo to break up circular dependencies between toolchain/gcc/gdb/or1ksim? | 18:39 |
| _franck_ | blueCmd_: it runs for some time then exit with Error 1 | 21:00 |
| _franck_ | olofk: did you try to run orpsoc or1200-generic --sim verilator --or1k-elf-load=... lately ? | 21:04 |
| _franck_ | %Error: Unknown warning specified: -Wno-fatal | 21:04 |
| _franck_ | if I remove this flag, I get ....bench/verilog/uart16550_model.v:20: Cannot find include file: wb_bfm_params.v | 21:05 |
| _franck_ | then I let down for tonight :) | 21:05 |
| blueCmd_ | jeremybennett: would you consider merging the patch without tests for it, or is that a blocker? | 21:23 |
| jeremybennett | blueCmd_: Well it's not an absolute blocker, but it is something we try to avoid. I realize some things are quite hard to test. | 21:48 |
| jeremybennett | When I took over Or1ksim it had not tests and was somewhat "unreliable". Most of what I did was to write tests, so it became much more credible as a golden reference for the architecture. | 21:48 |
| jeremybennett | Ultimately the idea is that the same set of tests should run on OpenRISC implementations as well. | 21:49 |
| jeremybennett | What causes difficulty writing the tests? | 21:49 |
| olofk | _franck_: Yeah, I messed up a bit when I added the uartmodel. It's not possible to run it with verilator | 22:01 |
| olofk | Two possible solutions: | 22:02 |
| olofk | 1. Quick'n'dirty: Add `ifdef VERILATOR in all the wb_bfm modules that can't be synthesized | 22:03 |
| olofk | 2. The right way: Extend the dependency handling so that wb_bfm is only pulled in when icarus or modelsim is used | 22:03 |
| blueCmd_ | jeremybennett: writing them are fine, but I can't manage to get it to run without creating a new build environment suited for newlib | 22:09 |
| jeremybennett | blueCmd_: But you won't be able to run any Or1ksim tests in that case. And even if you don't test your own patch, you need to make sure you haven't broken anything else. | 22:14 |
| jeremybennett | What is the problem with creating the newlib toolchain? | 22:14 |
| blueCmd_ | jeremybennett: yeah, I know that deep in - I guess I'm just trying to take the easy way out :) | 22:15 |
| blueCmd_ | jeremybennett: well, my environment and build scripts are not set up for newlib, and I have never built a newlib toolchain before | 22:15 |
| jeremybennett | Well I haven't done it for a while, but running bld-all.sh with default arguments pretty much does it (IIRC there is even a flag to stop it buing the uClibc toolchain). | 22:22 |
| blueCmd_ | hm, I wouldn't even know where that script is. I have my very own scripts (glibc is different :P) | 22:23 |
| blueCmd_ | oh well, I'll get around to build it sometime I guess | 22:23 |
| stekern | blueCmd_: that's for the or32- toolchain | 22:23 |
| blueCmd_ | stekern: the old svn repo thing? | 22:24 |
| stekern | yes | 22:24 |
| jeremybennett | blueCmd_: stekern is right - the scripts are for the or32 tool chain. I don't know what people do for the or1k tool chain. | 22:24 |
| stekern | follow the instructions here: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 22:25 |
| jeremybennett | But the approach is generic - link all your sources into a unified tree, configure with --with-newlib and then make the components you need (probably make all-build all-binutils all-gas all-ld all-gcc all-target-libgcc) | 22:25 |
| jeremybennett | Or as stekern has pointed out there are instructions. | 22:26 |
| stekern | blueCmd_: someone posted this script that does what the instruction says: http://pastie.org/8627626 | 22:26 |
| jeremybennett | BTW stekern why the two pass build. The whole thing with newlib is you configure with -newlib and do a single pass. | 22:26 |
| blueCmd_ | stekern: thanks, I'll look at it in the week | 22:26 |
| jeremybennett | sorry --with-newlib | 22:26 |
| stekern | jeremybennett: the instruction came from my "recipe" that I gave to juliusb_ and he (kindly) put it on the wiki, no-one revised them | 22:27 |
| stekern | that said - how does gcc pick up where newlib is? | 22:29 |
| jeremybennett | It's in the unified tree. | 22:31 |
| stekern | ah, ok, but that just seems messy to setup with how we have things now | 22:32 |
| jeremybennett | The GNU build system is all built around the assumption that it is in one humungous tree. | 22:32 |
| stekern | since we have the unified tree, sans gcc | 22:32 |
| jeremybennett | Something for the future. | 22:32 |
| jeremybennett | Yes - the unified tree as we have it (which I know was my idea) is now looking rather awkward given the merger of binutils & gdb in git. | 22:33 |
| stekern | but gcc is not in the sourceware tree, so it doesn't really fit in to that picture | 22:33 |
| jeremybennett | Just an accident of history. That's why the tree linker script is in the GCC utils directory. | 22:33 |
| jeremybennett | One day, we will finally get it all put together in one coherent repo. Until then every GCC developer on the planet has to build their own unified tree from the separate repos. | 22:34 |
| stekern | ... or just build it in two steps, it's not a huge big of deal | 22:35 |
| stekern | keeps my feet warm here in the basement ;) | 22:35 |
| blueCmd_ | I'm just happy we don't have the 3-stage build you usually have | 22:37 |
| blueCmd_ | 3 pass* | 22:37 |
| stekern | jeremybennett: but you have a point with the awkwardness, I guess it wouldn't be too hard to rebase our commits ontop of the official git repos though | 22:39 |
| stekern | something for a rainy day | 22:41 |
| jeremybennett | stekern: No - I suppose if I complain I ought to make the fix myself | 22:41 |
| jeremybennett | blueCmd_: 3 pass - I thought CrossToolNG had just gone up to 4 passes? | 22:41 |
| blueCmd_ | jeremybennett: maybe, but I can build glibc + gcc AFAIK with just 2 passes over gcc | 22:42 |
| jeremybennett | I thought glibc had the same integration as newlib, so you can build in just 1. The only issue would be if you needed to pick up Linux headers. | 22:47 |
| jeremybennett | It's a known problem with GCC - circular library dependencies. | 22:47 |
| --- Log closed Mon Jan 13 00:00:51 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!