IRC logs for #openrisc Friday, 2012-12-21

andresjkDoes 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:
mor1kxmor1kx/master ac978a5 Stefan Kristiansson: (pronto)espresso/cpu: remove ic/dc spr signals...05:54
stekernandresjk: depends what you mean by debugging the wishbone signal05:55
stekernyou can read/write peripherals connected to the wishbone bus05:55
stekernthat's about it05:55
stekernblueCmd: 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 apply05:57
-!- Netsplit *.net <-> *.split quits: simoncook, juliusb, gxti, Xark10:44
-!- Netsplit over, joins: simoncook, juliusb, Xark, gxti10:46
blueCmdstekern: ah cool, are those tests something I can run aswell?12:04
stekernyes, it's a bit work to setup, but not that bad12:09
blueCmdrelro will probably not be a big deal, but I'm more afraid of CFI12:10
stekernyou'll need this:
stekernit has the path to the installed gcc hard-coded to /opt/or1k/bin so you need to change that if you have it somewhere else12:14
stekernand then you'll need to setup or1ksim with tun/tap which should run linux with ftp enabled12:15
blueCmdI keep seeing Embecosm, how are they involved?12:15
stekernEmbecosm is jeremybennetts company12:16
stekernhe can probably tell himself more in-depth how they are involved, but they have done a lot of work on the toolchain and or1ksim etc12:17
blueCmdah ok. it's nice knowing the contributors12:19
stekernanyway, once you have linux under or1ksim running, you start the test-suite by running:12:19
stekernmake check RUNTESTFLAGS="--target_board=or1k-linux-sim --target_triplet=or1k-unknown-linux-gnu" OR1K_IP=""12:20
stekernin the 'build-or1k-gcc' directory12:21
* blueCmd is logging this, keep going12:23
stekernI'm all done :)12:23
stekernthere are some more indepth instructions howto setup tun/tap in or1ksim in the or1ksim documentation12:24
blueCmdah great12:25
blueCmdstekern: btw, I did find the problem12:25
blueCmdfor the eh_frame thing12:25
blueCmdmany architectures set -fno-asynchronous-unwind-tables for crtstuff in gcc12:25
blueCmdI tried doing that but on or1k it seemed to exactly nothing12:25
blueCmdso I used -fno-dwarf2-cfi-asm until I can find something better12:26
stekernand what should be done to the linux running in or1ksim is described here:,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fgnu-stable%2Fdoc%2Ftesting.txt12:26
stekernmaybe we default to no-asynchronous-unwind-tables12:34
blueCmdwell, then it doesn't do the same as it does in other architectures12:39
blueCmdwhich isn't far fetched12:39
stekern -fasynchronous-unwind-tables doesn't show up at least13:01
stekern(it does on my ws)13:01
stekernnot sure that makes -fno-asynchronous-unwind-tables default though13:03
blueCmdit shows up on my x8_64 reference at least13:13
blueCmdnot or1k13:13
blueCmdsame as you13:14
blueCmdnice command that, I didn't know about it13:14
stekerngoogle showed me the way ;)13:14
stekernbut I knew it should exist, since I've seen that output generated before13:14
blueCmdhah, I've been chasing a ghost for the last hour (different problem).13:18
blueCmdI was debugging why GNU_EH_FRAME extensions wasn't enabled, but it was. I just missread it as GNU_STACK13:18
* blueCmd sighs13:18
blueCmdstekern: 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
blueCmdor1k 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 stuff13:44
stekerncan't we just use the -muclibc and -mglibc flags?13:52
blueCmdperhaps, I haven't research that much in it, it's just the way other architectures have gone.13:53
blueCmdhm, maybe uclibc will work with the glib headers, I will do some research and get back to you.13:55
blueCmdbfin does just that, use glibc-stdint with a target named uclibc so perhpas that works13:55
stekernI kind of would like to be able to use or1k-linux for both13:56
blueCmdyeah, that would be the best - no doubt13:57
stekernand my impression is that the muclibc and mglibc flags are exactly for this purpose13:58
blueCmdright - I think it defaulted to -mglibc with these flags, but that is probably easy to change14:00
stekern'it' and 'flags' being? we default to -muclibc, but yes that's easy to change14:02
blueCmdsorry, 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 speak14:06
stekernah, I see14:08
stekernyeah, the DRIVER_SELF_SPECS in or1k/linux-elf.h is what makes it default to -muclibc14:09
stekernanyways, 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 preferred14:20
blueCmdhah, I *just* figured that syntax out :P14:22
blueCmdI'm thinking about how to tell GCC what flag it should use by default. I think that's what the target is used for14:29
blueCmdbut 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
stekernhmm, yeah14:35
stekernmaybe 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 mglibc14:36
stekernbut you can still use or1k-linux with uclibc with the -muclibc flag14:36
blueCmdah yeah, I will figure something out14:38
stekernyeah, don't let bike-shed issues stall you :P14:38
blueCmdbike-shred issues? :P14:39
blueCmdsorry -r14:41
blueCmdi googled bike-shred issues and confusion ensured14:41
blueCmdyepp, I see :)14:42
blueCmdwell, I think these issues are quite important - they will be hard to change further down the road14:42
blueCmdstekern: you talked about some hardcoded libc library name17:31
blueCmdcan you recap a bit about that? I think that's the only oddity left17:34
blueCmdI think I solved it, quite nice if I may say so myself :)18:01
stekernblueCmd: this:
stekernwas that what you found?18:05
blueCmdah, I knew I had seen that somewhere18:06
blueCmdwell, not really18:06
blueCmdI added support for -dynamic_linker which adds:18:06
blueCmd  INTERP         0x0007ae 0x000007ae 0x000007ae 0x00014 0x00014 R   0x118:06
blueCmd      [Requesting program interpreter: /lib/]18:06
blueCmd  INTERP         0x0007ae 0x000007ae 0x000007ae 0x0000d 0x0000d R   0x118:06
blueCmd      [Requesting program interpreter: /lib/]18:06
blueCmddepending if you have -mglibc or -muclibc18:07
blueCmdwhat does ELF_DYNAMIC_INTERPRETER do?18:07
blueCmdmind you I haven't tested if it works yet, I just know that the sections look nice18:08
stekernit does the same thing18:10
stekern-dynamic_linker overrides it18:10
blueCmdah ok18:10
stekernbut the -dynamic_linker only works when using gcc as a wrapper, right?18:10
stekernI mean, that's in gcc, right?18:11
blueCmdhm, it is passed to collect2 atleast18:11
blueCmdI can check if ld gets the argument18:11
stekernso if you'd do a manual as + ld it'd still use ELF_DYNAMIC_INTERPRETER18:11
stekernI think you can solve it in the emulparams18:12
stekernIIRC I saw x86 doing something like that18:12
blueCmdwell ld is called with -dynamic_linker18:12
blueCmdthe argument to that is computed by gcc18:13
blueCmdif that's what your asking18:13
blueCmdso yes, if you would do as + ld without -dynamic_linker it wouldn't know what to use18:13
stekernmmm, but otoh, for that to work anyways, we'd need a different target18:14
blueCmd    ELF_INTERPRETER_NAME=\"/lib/amd64/\"18:16
blueCmdis that it?18:16
blueCmdseems to be yes18:16
blueCmdbut I don't think it will be a major thing to default to that if gcc can handle it18:18
stekernyes, that's what I meant18:22
blueCmdstekern: this isn't a massive commit either ;)
blueCmdIt should be standalone, haven't tested it without my other patches though18:30
stekernlooks good18:30
stekernbut shouldn't it be /usr/lib/
blueCmdhm, do we want it to be that? no other arch had /usr in it18:31
stekerntbh, I'm not sure18:32
blueCmdthey are usually symlinked to eachother, no?18:32
blueCmdon recent systems18:32
blueCmdperhaps not so much embedded though18:32
blueCmdwell, 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
stekernwhere does glibc install it by default?18:34
stekernrun grep -rI "/usr/lib/" * in or1k-src18:34
stekernor rather "/lib/"18:35
stekernseems to be pretty mixed18:35
blueCmdno match at all in gcc18:37
stekernall good then ;)18:41
blueCmdstekern: you have a pull request for that patch standalone, it seems to work well19:25
stekernok, I'll put that in at the same when I run the regression tests19:30
stekernstill running a reference run19:31
stekernseems there are a couple of new regressions after Peter's resync with upstream19:31
stekernah, well... there are some 5000 new tests that are passing too19:33

Generated by 2.15.2 by Marius Gedminas - find it at!