IRC logs for #openrisc Friday, 2014-09-05

--- Log opened Fri Sep 05 00:00:38 2014
poke53281My guess is, that it works for you.01:21
poke53281Don't use my toolchain, use yours.01:21
poke53281It works under qemu-user.01:34
poke53281Is the kernel involved in a try/catch block? signals maybe?01:35
poke53281Hmm, I have still this GLIBC stuff in my binary. But I reinstalled the whole toolchain01:45
stekernpoke53281: don't be sad, the X I built didn't work at all03:46
stekern...and trying to roll back to your binaries didn't work neither03:47
poke53281Maybe I have found the error03:48
poke53281it's in my build of the toolchain03:48
poke53281I forgot a symbolic link which is very very important.03:49
poke53281stekern: exchange your toolchain.make with the following
poke53281and rerun the "make musl_toolchain"03:51
stekernI get this: (EE) [mi] EQ overflow continuing.  100 events have been dropped.03:51
stekernin X03:52
poke53281for this c++ code?03:52
poke53281Hmm, I never saw this error.03:52
poke53281But it looks like it's your event code.03:52
stekernit worked before03:53
poke53281well, you have the .tar.bz2 files. Just create a new sysroot03:53
poke53281even a removal from a existing sysroot should be possible with some bash scripting.03:54
stekernwell, I have a lot of other stuff in my "old" sysroot, so I don't want to do that03:55
stekern...and rolling back to the tar.bz2 haven't worked so far03:55
stekernln -sf . /opt/cross/or1k-linux-musl/or1k-linux-musl/usr03:58
stekernwhat is that supposed to do?03:58
poke53281Yes that's it03:58
poke53281# make the sysroot usr directory03:59
poke53281if [ ! -e "$PREFIX"/"$TRIPLE"/usr ]03:59
poke53281mkdir -p "$PREFIX"/"$TRIPLE"03:59
poke53281ln -sf . "$PREFIX"/"$TRIPLE"/usr03:59
poke53281this is from musl-cross03:59
poke53281you have to delete the directory first.04:00
poke53281I think, that otherwise the toolchain cannot find certain directories and files.04:00
stekernah.. but I already have that04:00
poke53281Yes, in your toolchain. But I use my own scripts.04:01
stekernsince I just installed your version ontop of my old04:01
poke53281and this is the reason for the glibc problem. At least, I hope that this is the reason.04:01
stekernso that's why my toolchain worked even though I had compiled from your scripts04:01
poke53281I think so.04:02
poke53281By the way. The main difference is the --sysroot option. Otherwise musl.-cross and mine should be identical.04:02
poke53281In 5 minutes I know if my glibc problem is solved.04:04
poke53281ahh, I will put the ln to another position in the code.04:05
stekernyour cpp test crashes04:08
stekernwhy do you put everything in /usr/lib instead of following the musl-cross?04:09
poke53281you mean libgcc and libstdc?04:09
stekernok, it crashed because my mishmash of your stuff and mine,04:09
stekernremoving my /lib/ made it worl04:10
stekern~ # ./cpptest04:10
stekernError 4204:10
poke53281yes, sorry. I should follow it. In the end, it was not important. Maybe I followed archlinux here :)04:11
poke53281Hmm, stil. A diff of "find ." between musl-cross and mine is still different04:12
poke53281But, I am close :)04:13
stekernhmmm... now I get this: Error relocating /usr/lib/ unsupported relocation type 8804:14
poke53281No, it's identical. I don't create or1k-musl-linux04:14
poke53281did you execute a "make musl"04:14
daliasstekern, i'm guessing non-PIC .o's from a .a file got linked into libX11.so04:15
stekerndalias: very possible, this rootfs is starting to look like frankensteins monster though, I should just start over04:16
poke53281this happens to m very often. So I started to make this packages.04:17
poke53281arghh, I have still the glibc problem.04:20
poke53281the second stage must be wrong somehow04:21
poke53281second stage of gcc04:21
daliasthe glibc problem may not actually be glibc, but libgcc_s having symbols with GLIBC_2.0 as their version string04:23
dalias(yes this is gross gnu behavior)04:24
poke53281I have musl-cross which works fine and I have my build-script which should be almost identical04:24
poke53281I have run line by line through musl-cross. Debugged every command and still.04:24
daliasyou apply all the patches from musl-cross, including adding a target that's or1k-linux-musl rather than or1k-linux-gnu ?04:24
stekerndalias: we keep a seperate branch in our gcc port that has that04:25
poke53281yes, no patches for gcc necessary.04:25
poke53281That's my script04:30
poke53281umm, there could be another stupid reason.04:32
poke53281All sources are development branches.04:32
poke53281except of gcc04:33
poke53281and linux04:35
poke53281lol, found it. It's indeed my sysroot option in the gcc stage 204:36
poke53281the one and ponly important change04:37
poke53281If I remove this option my binaries get rid of glibc04:39
poke53281Yes, weird05:05
poke53281top:bad bottom: good06:00
poke53281I am unsure what this tables mean06:01
daliasi think you'd have to hunt down the gcc build logic for whether/how config/libgcc-glibc.ver gets used06:09
daliasnone of this should happen if you're not using libgcc_s.so06:09
daliasand is really backwards and shouldn't be used06:09
stekerndalias: by "not using", do you mean not build it at all?06:11
daliasthat's one option i actually use :)06:11
poke53281Hey, stekern. This was my question.06:12
dalias--enable-shared=[list] (list of libs you want shared versions of)06:12
daliasomitting libgcc from it works well06:12
poke53281libgcc is then linked statically?06:13
daliasthat's supposed to be the normal way it works except for the exception-handling related parts06:13
poke53281at the moment I don't see any benefits for a static libgcc06:14
daliassaving 8k per process would be one06:14
daliasreduced startup time06:15
poke53281is this enough. Then I will try it.06:17
poke53281I compile languages=c,c++06:17
daliasi also have libgomp in mine, but it's not a big deal for testing06:18
poke53281libgmp, libmpfr too then06:19
daliasthose are libs gcc links against, not target libs06:20
daliasgomp is not gmp-related06:20
daliasgomp is gnu OpenMP06:20
poke53281ahh, Ok06:20
poke53281stekern: For me it is not obvious if libgcc and libstdc++ are installed in /usr/lib or /lib06:48
poke53281for musl-cross both are the same.06:48
poke53281because of the symbolic link06:48
daliasnormally would be /usr/lib06:51
olofkMost confusing python 3 porting problem yet06:57
poke53281Interesting. No he seems to omit libgcc completely.06:57
olofkThey renamed raw_input to input in python 3. Problem is, input was already used in python2 and did something slightly different06:57
daliaspoke53281, ?06:57
daliasthe static libgcc files are just in the gcc lib directory06:58
daliasnot /usr/lib06:58
poke53281O, they are still there.06:58
poke53281olofk: There must be a reason why every distribution has always 2-3 python versions installed06:59
poke53281dalias: I think libatomic  and libsupc++ should be also in the enable-shared list07:00
poke53281olofk: I am unsure whether it was good idea to break the compatibility wit the old python versions.07:02
poke53281Would be nice if python3 would directly reckognize python2 code and then switch the executable if available.07:04
olofkpoke53281: Me too. They got a lot of crap for doing that. I try to keep FuseSoC working with 2.7 and 3. Got a few workarounds but works fine for the most part07:04
olofkYes, that's a great idea actually07:04
olofkMany scripts set the shebang to a specific version though07:06
daliaswhat is libatomic for?07:06
daliasi thought it was just for doing fake atomics on broken systems that lack real atomics...07:06
poke53281Don't know. But it is installed.07:06
poke53281olofk: This sounds like a different behavior for libraries and not for language features. And this is really not good modern design. There is something called namespaces or libraries. If one library gets old, just make a new one and keep the old. If you do it right, they will never interfere.07:08
poke53281in C++ we have the namespace std. If they want to start a new library, they might call it std2. And within that namespace they objects can have the same name. Because you define them by telling also the namespace like std:string.07:11
olofkI think the big problem with python3 was that they renamed built-in functions and types and changed type signatures for some common functions07:23
olofkYes! My wizard for FuseSoC is pretty much done now09:39
olofkFuseSoC can now clone and pull orpsoc-cores with built-in init and update commands09:40
hansfbaierolofk: nice09:42
olofkAnd not it's pushed!10:02
stekernpoke53281: typo in X.make - xli: or1k-linux-musl.gcc => ork-linux-musl-gcc10:12
olofkHaha (thanks to ysionneau for the tip)10:26
olofkGahh.. I can't make it work. Should probably ask for help on the OpenCores forum10:33
olofkI need to make teh DUAL FIXED FREQUENCY OSCILLATOR. plz send me code to nothomework@hotmail.com10:33
olofkTip of the day. Put this in a udev rule to allow openocd and jtagd as regular user11:07
olofkATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="664", GROUP="plugdev"11:07
olofkand add yourself to the plugdev group in that case11:07
olofk_franck__: I'm trying to use the OpenOCD telnet interface to load elf files as described in the orconf2013 tutorial, but it just says "Invalid ELF File, no program headers". Any ideas?11:12
olofkjuliusb_ might have some input here too I guess11:12
olofkhm.. a linux image seems to load fine11:13
olofkBut my small bare-metal app doesn't11:13
olofkfile tells me that only one of the is executable11:15
olofkolof@olof-VirtualBox:~/openrisc$ file led_blink11:15
olofkled_blink: ELF 32-bit MSB  relocatable, OpenRISC, version 1 (SYSV), not stripped11:15
olofkolof@olof-VirtualBox:~/openrisc$ file linux/vmlinux11:15
olofklinux/vmlinux: ELF 32-bit MSB  executable, OpenRISC, version 1 (SYSV), statically linked, BuildID[sha1]=595d569fb6b075f34df8d7ebc97809ef2bb3766b, not stripped11:15
heshamDoes setting TTMR[TP] = 1048281 and tick timer to restart mode, means that it will take (1048281 * 10) ns interval between every tick interrupt? (Given that I configured or1ksim to operate on 10ns/ 100 MHz frequency)11:56
olofkWhat kind of sorcery do I have to use to get an elf file with program headers from an assembler source file?12:35
olofkPassing it through ld seems to work, but I get a warning "or1k-elf-ld: warning: cannot find entry symbol _start; defaulting to 0000000000000000"12:44
olofkAnd the resulting file grows from 844 byte to 8.8k :)12:44
stekerncan our elf-loader read the first file?12:45
olofkAt least it works12:46
stekernI think I stumbled onto something similar, and _franck__ mentioned that it's a bug in openocd12:47
stekerniirc, I resorted to using a .bin instead12:47
olofkaha. I found a patch for OpenOCD from _franck__ that tries to fix this :)12:52
olofkahh. you found thta too :)12:52
olofkThe elf-loader in orpsoc-cores work fine12:53
-!- Netsplit *.net <-> *.split quits: kiwichris12:54
olofkEven more fun is that _franck__ used led_blink as an example of an ELF file without program headers :)12:57
-!- Netsplit *.net <-> *.split quits: kiwichris13:25
-!- Netsplit over, joins: kiwichris13:27
-!- Netsplit *.net <-> *.split quits: kiwichris14:18
-!- Netsplit over, joins: kiwichris14:27
_franck_^ as you said, you need to pass your led_blink.o to ld to get a program header15:54
-!- _franck__ is now known as _franck_19:40
poke53281stekern: corrected22:19
poke53281Now I will try to compile everything with a static libgcc22:23
--- Log closed Sat Sep 06 00:00:40 2014

Generated by 2.15.2 by Marius Gedminas - find it at!