| andresjk | hi | 04:22 |
|---|---|---|
| andresjk | Does anyone knows if its possible to debug the wishbone signal using the or32 debugger? | 04:23 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/ac978a5ad300d080e8936b76a0593113179f7a11 | 05:54 |
| mor1kx | mor1kx/master ac978a5 Stefan Kristiansson: (pronto)espresso/cpu: remove ic/dc spr signals... | 05:54 |
| stekern | andresjk: depends what you mean by debugging the wishbone signal | 05:55 |
| stekern | you can read/write peripherals connected to the wishbone bus | 05:55 |
| stekern | that's about it | 05:55 |
| stekern | blueCmd: thanks for the patch by the way, I'm going to apply it locally and run the regression tests, if there are no new regressions I reckon it's fine to apply | 05:57 |
| -!- Netsplit *.net <-> *.split quits: simoncook, juliusb, gxti, Xark | 10:44 | |
| -!- Netsplit over, joins: simoncook, juliusb, Xark, gxti | 10:46 | |
| blueCmd | stekern: ah cool, are those tests something I can run aswell? | 12:04 |
| stekern | yes, it's a bit work to setup, but not that bad | 12:09 |
| blueCmd | relro will probably not be a big deal, but I'm more afraid of CFI | 12:10 |
| stekern | you'll need this: https://github.com/openrisc/or1k-dejagnu | 12:11 |
| stekern | + http://oompa.chokladfabriken.org/tmp/or1k-linux-sim.exp | 12:13 |
| stekern | it has the path to the installed gcc hard-coded to /opt/or1k/bin so you need to change that if you have it somewhere else | 12:14 |
| stekern | and then you'll need to setup or1ksim with tun/tap which should run linux with ftp enabled | 12:15 |
| blueCmd | I keep seeing Embecosm, how are they involved? | 12:15 |
| stekern | Embecosm is jeremybennetts company | 12:16 |
| blueCmd | aha | 12:17 |
| stekern | he can probably tell himself more in-depth how they are involved, but they have done a lot of work on the toolchain and or1ksim etc | 12:17 |
| blueCmd | ah ok. it's nice knowing the contributors | 12:19 |
| stekern | anyway, once you have linux under or1ksim running, you start the test-suite by running: | 12:19 |
| stekern | make check RUNTESTFLAGS="--target_board=or1k-linux-sim --target_triplet=or1k-unknown-linux-gnu" OR1K_IP="192.168.255.200" | 12:20 |
| stekern | in the 'build-or1k-gcc' directory | 12:21 |
| * blueCmd is logging this, keep going | 12:23 | |
| stekern | I'm all done :) | 12:23 |
| stekern | there are some more indepth instructions howto setup tun/tap in or1ksim in the or1ksim documentation | 12:24 |
| blueCmd | ah great | 12:25 |
| blueCmd | stekern: btw, I did find the problem | 12:25 |
| blueCmd | for the eh_frame thing | 12:25 |
| blueCmd | many architectures set -fno-asynchronous-unwind-tables for crtstuff in gcc | 12:25 |
| blueCmd | I tried doing that but on or1k it seemed to exactly nothing | 12:25 |
| blueCmd | so I used -fno-dwarf2-cfi-asm until I can find something better | 12:26 |
| stekern | and what should be done to the linux running in or1ksim is described here: http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fgnu-stable%2Fdoc%2Ftesting.txt | 12:26 |
| stekern | maybe we default to no-asynchronous-unwind-tables | 12:34 |
| blueCmd | well, then it doesn't do the same as it does in other architectures | 12:39 |
| blueCmd | which isn't far fetched | 12:39 |
| stekern | http://pastie.org/5560940 | 13:01 |
| stekern | -fasynchronous-unwind-tables doesn't show up at least | 13:01 |
| stekern | (it does on my ws) | 13:01 |
| stekern | not sure that makes -fno-asynchronous-unwind-tables default though | 13:03 |
| blueCmd | it shows up on my x8_64 reference at least | 13:13 |
| blueCmd | not or1k | 13:13 |
| blueCmd | same as you | 13:14 |
| stekern | yep | 13:14 |
| stekern | http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/cpp/win/copts/common_options/option_fasynchronous_unwind_tables.htm | 13:14 |
| blueCmd | nice command that, I didn't know about it | 13:14 |
| stekern | google showed me the way ;) | 13:14 |
| blueCmd | :P | 13:14 |
| stekern | but I knew it should exist, since I've seen that output generated before | 13:14 |
| blueCmd | hah, I've been chasing a ghost for the last hour (different problem). | 13:18 |
| blueCmd | I was debugging why GNU_EH_FRAME extensions wasn't enabled, but it was. I just missread it as GNU_STACK | 13:18 |
| * blueCmd sighs | 13:18 | |
| stekern | ;) | 13:19 |
| blueCmd | stekern: there are a couple of headers I would want to use in gcc with glibc, would it be OK to rename or1k-linux to or1k-uclibc? or should I use or1k-glibc ? | 13:43 |
| blueCmd | or1k haven't been released yet so I figure it would probably be nicest to have it named or1k-uclibc, but then again I don't know how much it messes up with other stuff | 13:44 |
| stekern | can't we just use the -muclibc and -mglibc flags? | 13:52 |
| blueCmd | perhaps, I haven't research that much in it, it's just the way other architectures have gone. | 13:53 |
| blueCmd | hm, maybe uclibc will work with the glib headers, I will do some research and get back to you. | 13:55 |
| blueCmd | bfin does just that, use glibc-stdint with a target named uclibc so perhpas that works | 13:55 |
| stekern | I kind of would like to be able to use or1k-linux for both | 13:56 |
| blueCmd | yeah, that would be the best - no doubt | 13:57 |
| stekern | and my impression is that the muclibc and mglibc flags are exactly for this purpose | 13:58 |
| blueCmd | right - I think it defaulted to -mglibc with these flags, but that is probably easy to change | 14:00 |
| stekern | 'it' and 'flags' being? we default to -muclibc, but yes that's easy to change | 14:02 |
| blueCmd | sorry, gcc defaulted to -mglibc when i added gnu-user.h and glibc-stdint.h instead of uclibc-stdint.h. I also removed DRIVER_SELF_SPECS which probably changed this behaviour - testing as we speak | 14:06 |
| stekern | ah, I see | 14:08 |
| stekern | yeah, the DRIVER_SELF_SPECS in or1k/linux-elf.h is what makes it default to -muclibc | 14:09 |
| stekern | anyways, if it proves 'impossible' to handle it with the mglibc flag, I think or1k-linux-uclibc for uclibc and or1k-linux for glibc is what is preferred | 14:20 |
| blueCmd | hah, I *just* figured that syntax out :P | 14:22 |
| stekern | nice | 14:23 |
| blueCmd | I'm thinking about how to tell GCC what flag it should use by default. I think that's what the target is used for | 14:29 |
| blueCmd | but it would be nicer with a configure-flag I suppose. it would be much more hidden and perhaps harder to debug though (two compilers, same name w/ different default libs) | 14:30 |
| stekern | hmm, yeah | 14:35 |
| stekern | maybe the right road is to have two targets after all, one or1k-linux-uclibc that defaults to muclibc and a or1k-linux that defaults to mglibc | 14:36 |
| stekern | but you can still use or1k-linux with uclibc with the -muclibc flag | 14:36 |
| blueCmd | ah yeah, I will figure something out | 14:38 |
| stekern | yeah, don't let bike-shed issues stall you :P | 14:38 |
| blueCmd | bike-shred issues? :P | 14:39 |
| stekern | http://www.youtube.com/watch?v=1OJW6ayY488 | 14:41 |
| blueCmd | haha | 14:41 |
| blueCmd | sorry -r | 14:41 |
| blueCmd | i googled bike-shred issues and confusion ensured | 14:41 |
| stekern | http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality | 14:42 |
| blueCmd | yepp, I see :) | 14:42 |
| stekern | :P | 14:42 |
| blueCmd | well, I think these issues are quite important - they will be hard to change further down the road | 14:42 |
| stekern | true | 14:45 |
| blueCmd | stekern: you talked about some hardcoded libc library name | 17:31 |
| blueCmd | can you recap a bit about that? I think that's the only oddity left | 17:34 |
| blueCmd | I think I solved it, quite nice if I may say so myself :) | 18:01 |
| stekern | blueCmd: this: https://github.com/openrisc/or1k-src/blob/or1k/bfd/elf32-or1k.c#L59 | 18:05 |
| stekern | was that what you found? | 18:05 |
| blueCmd | ah, I knew I had seen that somewhere | 18:06 |
| blueCmd | well, not really | 18:06 |
| blueCmd | I added support for -dynamic_linker which adds: | 18:06 |
| blueCmd | INTERP 0x0007ae 0x000007ae 0x000007ae 0x00014 0x00014 R 0x1 | 18:06 |
| blueCmd | [Requesting program interpreter: /lib/ld-uClibc.so.0] | 18:06 |
| blueCmd | or | 18:06 |
| blueCmd | INTERP 0x0007ae 0x000007ae 0x000007ae 0x0000d 0x0000d R 0x1 | 18:06 |
| blueCmd | [Requesting program interpreter: /lib/ld.so.1] | 18:06 |
| blueCmd | depending if you have -mglibc or -muclibc | 18:07 |
| blueCmd | what does ELF_DYNAMIC_INTERPRETER do? | 18:07 |
| blueCmd | mind you I haven't tested if it works yet, I just know that the sections look nice | 18:08 |
| stekern | it does the same thing | 18:10 |
| stekern | -dynamic_linker overrides it | 18:10 |
| blueCmd | ah ok | 18:10 |
| stekern | but the -dynamic_linker only works when using gcc as a wrapper, right? | 18:10 |
| stekern | I mean, that's in gcc, right? | 18:11 |
| blueCmd | hm, it is passed to collect2 atleast | 18:11 |
| blueCmd | I can check if ld gets the argument | 18:11 |
| stekern | so if you'd do a manual as + ld it'd still use ELF_DYNAMIC_INTERPRETER | 18:11 |
| stekern | I think you can solve it in the emulparams | 18:12 |
| stekern | IIRC I saw x86 doing something like that | 18:12 |
| blueCmd | well ld is called with -dynamic_linker | 18:12 |
| blueCmd | the argument to that is computed by gcc | 18:13 |
| blueCmd | if that's what your asking | 18:13 |
| blueCmd | so yes, if you would do as + ld without -dynamic_linker it wouldn't know what to use | 18:13 |
| stekern | mmm, but otoh, for that to work anyways, we'd need a different target | 18:14 |
| blueCmd | yeah | 18:16 |
| blueCmd | ELF_INTERPRETER_NAME=\"/lib/amd64/ld.so.1\" | 18:16 |
| blueCmd | is that it? | 18:16 |
| blueCmd | seems to be yes | 18:16 |
| blueCmd | but I don't think it will be a major thing to default to that if gcc can handle it | 18:18 |
| stekern | yes, that's what I meant | 18:22 |
| blueCmd | stekern: this isn't a massive commit either ;) https://github.com/blueCommand/or1k-gcc/commit/6ee313d0da6d1dd4b996dc4579ebafe48872137e | 18:29 |
| blueCmd | It should be standalone, haven't tested it without my other patches though | 18:30 |
| stekern | looks good | 18:30 |
| stekern | but shouldn't it be /usr/lib/ld.so.1 | 18:30 |
| stekern | ? | 18:30 |
| blueCmd | hm, do we want it to be that? no other arch had /usr in it | 18:31 |
| stekern | tbh, I'm not sure | 18:32 |
| blueCmd | they are usually symlinked to eachother, no? | 18:32 |
| blueCmd | on recent systems | 18:32 |
| blueCmd | perhaps not so much embedded though | 18:32 |
| blueCmd | well, glibc isn't ported yet so I figured I might as well name it whatever and change it or keep it in glibc :) | 18:33 |
| stekern | where does glibc install it by default? | 18:34 |
| stekern | run grep -rI "/usr/lib/ld.so.1" * in or1k-src | 18:34 |
| stekern | or rather "/lib/ld.so.1" | 18:35 |
| stekern | seems to be pretty mixed | 18:35 |
| blueCmd | no match at all in gcc | 18:37 |
| stekern | all good then ;) | 18:41 |
| blueCmd | stekern: you have a pull request for that patch standalone, it seems to work well | 19:25 |
| stekern | ok, I'll put that in at the same when I run the regression tests | 19:30 |
| stekern | still running a reference run | 19:31 |
| stekern | seems there are a couple of new regressions after Peter's resync with upstream | 19:31 |
| stekern | ah, well... there are some 5000 new tests that are passing too | 19:33 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!