IRC logs for #openrisc Friday, 2015-01-16

--- Log opened Fri Jan 16 00:00:57 2015
ysangkokpoke53282: i'm searching for instructions for how to cross-compile libffi for or1k, i'm working with v.3.2.1, it should feature the or1k support you added01:41
ysangkokpoke53282: i'm searching the toolchain-builder repo for "libffi" but i get nothing01:41
ysangkokpoke53282: oh, i needed to use or1k-linux-musl for --host instead of or1k... but this trick is not working with glib, so...01:57
poke53282libffi is cross compiled like any program07:51
poke53282search for libffi07:53
poke53282I don't understand the last message.07:58
poke53282It should work with glibc07:58
poke53282in the same way07:58
stekernno c08:02
poke53282Maybe it is too early in the morning, but I don't understand you message either.08:06
* poke53282 is searching for a coffee08:07
stekernglib, not glibc08:08
olofk_poke53282: glibc is the C library. glib is the library used by GTK et. al.08:08
poke53282Ahh, Ok08:15
poke53282Well, I thought he forgot the c because according to my knowledge libffi doesn't use glib.08:16
stekernno, but glib use libffi08:17
poke53282yes understood08:18
poke53282ysangkok. Look in sccripts/progs.make and search for glib08:19
poke53282and this is no trick, this the standard way to cross compile08:21
poke53282unfortunately it doesn't work for all programs this way.08:23
poke53282Actually,  a program that cross compiles out of the box is an exception.08:24
mpuHow to increase OpenCores community?08:31
poke53282good website08:34
mpuSite is not bad, but 2 things seems abandoned: "Worlds first open-source ASIC" and "Read our Newsletters".08:38
mpupoke53282: What is your point of view, about website. What to present in it?08:40
olofk_wallento: I'm looking at Is this still valid? The objdump command doesn't seem entirely correct and I can't figure out exactly what you're trying to do08:47
-!- olofk_ is now known as olofk08:48
poke53282@mpu: Sorry, are you asking generally about OpenCores or about OpenRISC?08:52
poke53282@mpu: The OpenCores website is in principle fine.08:54
mmpuI talk, about OpenCores. Site is good, but it is not so popular.09:10
olofkHas anyone run the binutils test suite?09:19
poke53282@mmpu: Well I guess, people move to github because of the community. I think, even sourceforge has a similar problem.09:20
-!- LoneTech_ is now known as LoneTech09:20
poke53282@olofk: I think yes. Long time ago.09:20
poke53282And I forgot the result. So it is pretty useless.09:21
olofkpoke53282: I'm trying to figure out how to run it. Got dejagnu, but after that, the procedure isn't very well documented09:21
olofkmake check fails09:21
poke53282Do you want to fix the limit problem with the 90MB libxul Firefox library and the hundred of thousands of relocations? :)09:22
poke53282yes, running the testsuite isn't easy.09:23
poke53282stekern uses or1ksim and I use qemu user mode.09:23
poke53282for the qemu part you need a sysroot and a static qemu compiled binary09:25
poke53282I guess, you can use this:
poke53282olofk: If I would compile dejagnu, we could run the testsuite inside the sysroot environment.09:37
poke53282Thanks to the number of script languages, which I compiled, this should be possible now.09:38
* poke53282 knows, what he will do in the evening today. 09:38
olofkpoke53282: hm... I assumed that the binutils were supposed to run in the host environment10:06
poke53282can't remember10:08
poke53282"make -k check" maybe?10:15
olofkI looked at the gentoo ebuild, and they used -k. Never heard of that before10:28
poke53282linux from scratch is using this as well.10:31
olofkI'll try a fresh rebuild and see if that helps10:32
olofkI read somewhere that the DEJAGNU env var should be set to something. Any ideas?10:36
poke53282for a testsuite running on the host I don't think so.10:37
poke53282RUNTESTFLAGS maybe10:43
poke53282My scripts, which probably won't work for you. But it could give you hints10:44
stekernins't it just to run 'make check' after you have configured with the right --target flag?10:50
olofkSeems to run now with a fresh build11:09
olofkhmm.. that was quick11:11
olofkThe forward test passes. Does this mean we can close ?11:28
olofkStill not entirely convinced that the tests were actually executed as intended11:38
olofkBut it's running the or1k allinsn test, so it might actually be correct11:41
* ams strokes olofk beard.11:50
olofkams: Whyyyyyyyyyyyyyyyy??!?!?!??!?!11:55
amsolofk: it is soft and fluffy11:56
poke53282olofk: The bug description says, that the test is deactivated12:06
poke53282but the bug report doesn't give a useful error description. A way, how to trigger the bug would be useful.12:07
olofkams: You got a point12:31
olofkpoke53282: It doesn't seem to be deactivated in upstream binutils. All gas tests seem to be run for or1k12:32
olofkBut in binutils-2.20 in opencores svn, the forward test is disabled12:35
olofkSo the bug is still valid for the or32 toolchain, but not for the or1k one12:36
olofkI'm leaning towards closing it as WONTFIX with an explanation that there is no active maintenance of the or32 toolchain.12:37
olofk_franck_: I saw your wb_altera_ddr_wrapper fixes. They make sense to apply12:38
olofkI got some fixes as well. The address width is hardcoded in a few places12:38
olofkI forked off the uart btw. Planning to kill off the 32 bit mode and VHDL implementation, and fix all the warnings14:20
olofkOh. and move config stuff from the defines file14:21
Me1234_how to compile with or1k-linux-gnu-gcc? All built by, initramfs form Running on de0_nano with de0_nano.dts.15:17
Me1234_When trying to run program compile with or1k-linux-gnu-gcc:-/bin/sh: /bin/a.out: not found15:18
Me1234_Actually file exists. Do i need some flags to gcc?15:18
olofkDid you use the default de0_nano_config as well?17:15
olofkFor the kernel17:15
Me1234olofk: no, only rootfs(initramfs biuilt into kernel). Config from bluecmd's or1k-devel. Enabled optimize for size and disabled block layer. Dts de0_nano.17:26
Me1234olofk: linux 3.15.0 downloaded by turnup.sh17:28
olofkWhat's this
Me1234olofk: modified to
Me1234olofk: Argument passed to script:
Me1234So, linux from here
olofkMe1234: I'm not sure I fully understand the script. Is this something that is supposed to be run inside of qemu?17:42
Me1234olofk: it is supposed to build and run or1k-linux in qemu ant run tests there.18:13
Me1234I do not need tests, I need only linux with glibc18:14
Me1234olofk: Means,that this config:
-!- zumbi_ is now known as zumbi18:48
olofkDoes anyone have an or32 toolchain installed? I want to know what is shown from "or32-elf-gcc --target-help". (bug 66. It works for or1k tc)21:01
stekernmine is broken21:07
stekernmpc has grown too old21:07
olofkIt's just a matter of choosing if it should be closed with FIXED, INVALID or WONTFIX21:14
olofkI should probably talk to jeremy about this. He's got the most interest in the or32 tc21:15
stekernI should fix my or32 toolchain anyway, it's good to have laying around for reference21:15
olofkIs it just a matter of rebuilding against a newer mpc, or do you need the older one?21:16
_franck_olofk: ok, I'll apply those fix to wb_altera_ddr_wrapper21:24
stekernit's "just" a matter of rebuilding, but there are those problems with texinfo that people complain about21:25
olofkI'm trying to figure out if bug 63 is still valid, but I can't make the example compile21:25
olofk_franck_: Great21:25
olofkstekern: Perhaps the precompiled ones might work21:26
stekernbut aren't those dated? compared to what's in svn I mean21:26
olofkYeah, true. I just assumed that no big changes were made since then21:28
olofkBut having something built from SVN head would be better21:28
olofkHmm.. why does "l.ori r3, r0, lo(SOME_SYMBOL)" work, but not "l.ori r3, r0, SOME_SYMBOL"?21:33
olofkI get "Error: unresolved expression that must be resolved" on the second one21:33
olofkNot my area of expertise, but I thought the lo() macro just picked out the lower 16 bits21:33
stekerniirc, that might have worked in or32, but the cgen stuff only generates the right relocations on lo/hi21:35
olofkSo it does the right thing (tm) on or1k by disallowing symbol names without hi/lo21:38
stekernwell, right thing(tm) is maybe a matter of preference21:39
stekernbut it's going to chop off the higher bits anyway, so you could as well require the user to be explicit21:40
olofkand the essence of the bug is that you get different behaviour if you're using lo, which I guess is not intended21:41
stekernthat's the code that handles it21:41
stekerndo you have a bug report about it? or are you just calling it a bug?21:42
stekernimo it's a feature ;)21:42
stekernor do you mean silently accepting without the lo(), but generating a faulty result?21:43
olofkI would like to close all the binutils bugs since we are upstream now21:46
stekernah, ok. well, I would consider that "fixed" in or1k then21:49
stekernsince obviously or32 did the wrong thing without the lo()21:50
stekerncomplaining about it is an improvement over that21:50
olofkI'm considering that a wontfix21:56
olofkAnd my friend google gave me some hints on what all this relocation business is about22:00
olofkI still haven't understood why we need a lot of different kinds of relocations though22:00
stekerna more specific question might be easier to answer ;)22:02
stekernwe have a couple that are bogus22:03
olofkBFD_RELOC_8, what's that good for?22:04
stekernbut the gist of it is that the assembler generates the and then the linker use them to determine what to do22:04
stekernthat's one of the bogus ones ;)22:05
olofkah :)22:05
olofkBogus or not. Something fixed bug 20 at least22:06
olofkIs cgen a part of binutils?22:10
stekerncgen is cgen, but binutils use it22:10
olofkI'm wondering since we have a separate cgen product in bugzilla22:11
stekernit's part of the (old) sourceware tree22:11
--- Log closed Sat Jan 17 00:00:59 2015

Generated by 2.15.2 by Marius Gedminas - find it at!