olofk | stekern: Thanks, I'll probably use parts of that. | 00:43 |
---|---|---|
olofk | Thinking about what I should implement next in orpsocv3. Any particular features that would make people use it instead of orpsocv2? | 00:44 |
olofk | I'm thinking of adding more simulator support (verilator or modelsim) or build support (xilinx or altera) | 00:45 |
juliusb | ah yeah that stuff is mostly in orpsocv2 right? | 02:10 |
juliusb | altera boards | 02:10 |
juliusb | modelsim, verilator, icarus | 02:10 |
juliusb | verilator is a bit annoying to do | 02:10 |
juliusb | but otherwise it's mostly covered right? | 02:10 |
stekern | juliusb: I'm tempted to extend the pipeline of cappuccino with a traditional seperated mem and writeback stage, in an attempt to kill the critical paths we see | 08:06 |
stekern | what do you reckon, should I modify cappuccino for that or make a new "cappuccino chiaro"? | 08:08 |
ConX | hello guys is there something I could read to better understand OR's assembly? | 17:42 |
ConX | I am not referring to the instruction set but to the general syntax (labels, branches etc) | 17:43 |
stekern | ConX: that's not very different than any other assembly | 17:53 |
ConX | stekern: so what will you suggest for me to read? the only assembly I have read is MIPS's | 18:00 |
ConX | and there are quite a lot I am not familiar with | 18:01 |
stekern | apart from the instruction set, it shouldn't be much different from mips | 18:04 |
stekern | here's a comparison from a simple hello_world: http://pastie.org/5098579 | 18:10 |
stekern | biggest difference is the $ prefix infront of registers, and that we are not using aliases for registernames such as ra, fp, sp | 18:12 |
ConX | thanks stekern | 18:15 |
ConX | do you know why I am getting a "undefined reference to `r0' | 18:16 |
ConX | " error when trying to compile an assemly code | 18:16 |
ConX | I am also quite confused of how #define works in a .S file | 18:22 |
stekern | ConX: can you paste the code where you get the undefined reference? | 19:06 |
stekern | ConX: for #define to work, you have to run the file through a preprocessor. that is automatically done when you use gcc as a shell to assemble | 19:18 |
ConX | stekern: sorry I was afk! | 19:29 |
stekern | np, we are all kind of slow responders in this chan :) | 19:31 |
ConX | :D | 19:32 |
ConX | I just use a "l.sw 0x4904(r0), r4" | 19:33 |
juliusb | stekern: ah, just the man i'm looking for - I've been stuff around with the Linux dynamic loader on my machine today | 19:37 |
juliusb | as you're someone who's recently played with this stuff, I'm wondering if you could give me some pointers | 19:37 |
juliusb | im on some ancient RHEL5 machine | 19:37 |
juliusb | and am trying to install a new glibc so i can run Chrome | 19:37 |
juliusb | turns out the loadero n this guy is so old it doesn't recognise the new GNU/Linux ELF ABI, only the old System V one | 19:38 |
juliusb | and I'm trying to switch over to using the new glibc for recent apps but the loader is just too old | 19:38 |
juliusb | so, I'm wondering how I can debug exactly a) what loader is being used and b) what it's doing | 19:38 |
juliusb | I have run with LD_DEBUG=all on and can see what's going on in terms of the libraries etc | 19:39 |
juliusb | but it doesn't tell me which loader is being used. I am not so foolish as to move/delete the /lib/ld-2.5.so | 19:39 |
juliusb | the new loader is in /new/lib/ld-2.14.so | 19:40 |
juliusb | but if I unlink the symlink from /lib/ld-linux.so.2 to /lib/ld-2.5.so and make it point to /new/lib/ld-2.14.so it appears to still use the old guy | 19:40 |
juliusb | if I then run ldconfig it just undoes the link of /lib/ld-linux.so.2 to /new/lib/ld-2.14.so and reverts it back to the old one | 19:41 |
juliusb | so, my next guess would be to just move the /lib/ld-2.5.so guy somewhere else, but am wondering if that will just screw me royally and require a me to boot off a live CD and restore it? | 19:42 |
juliusb | it seems like somewhere, somehow, the system knows that /lib/ld-2.5.so is the linker and there shall be no others | 19:42 |
juliusb | sorry, the loader, not linker | 19:42 |
juliusb | dynamic loader | 19:42 |
juliusb | anyway, I figured you were up to your neck in this stuff recently, and I presume wrote the loader for or1k, if you can advise :) | 19:43 |
stekern | ConX: weird, that should work.. | 19:52 |
stekern | juliusb: you could try if the ld supports running as standalone | 19:53 |
stekern | then you could run your exe with ld.so my.exe | 19:53 |
juliusb | yes I can do that and it appears to work (ie uses the new glibc, LD_DEBUG=all tells me this) but it'll then say, invoke a shell which'll go back to using the old loader and then it'll use the new glibc and break | 19:55 |
juliusb | i sort-of need some way of setting a variable or something which can only be temporary and will use a different loader | 19:55 |
stekern | hmm, sounds tricky ;) | 19:59 |
stekern | ConX: what toolchain are you using? | 20:01 |
stekern | juliusb: what happens if you add /new/lib to your LD_LIBRARY_PATH before you run chrome? | 20:15 |
juliusb | well, i'm trying to install it from a package | 20:17 |
juliusb | the loader just dies, however, whenever I try to do anything with /new/lib in LD_LIBRARY_PATH, because it doesnt support the ABI | 20:17 |
juliusb | mmm, also because I haven't isntalled glibc via the approved RPM way, it somehow thinks I still don't have it | 20:19 |
stekern | I assume just updating the whole machine isn't an option? =) | 20:22 |
juliusb | nah not yet :( | 20:24 |
juliusb | it's a machine I will need to keep largely compatible with our network | 20:25 |
juliusb | i could reinstall if I wanted | 20:25 |
juliusb | so the google-chrome executable is just a bash script | 20:25 |
juliusb | and that calls other stuff, like readlink, dirname, and that clearly uses the other loader | 20:25 |
juliusb | i'm very tempted to just copy the new loader over the old one | 20:26 |
juliusb | if i only had some sort-of backup | 20:26 |
juliusb | apparently sash, or statically linked shell, is a good thing to have | 20:26 |
juliusb | it has cp built in etc | 20:26 |
juliusb | maybe i'll do that | 20:26 |
juliusb | or busybox? | 20:26 |
stekern | what happens if you run the new linker on an old application? | 20:27 |
juliusb | yeah I think it works fine | 20:27 |
stekern | then it probably works copying over the old | 20:28 |
juliusb | mmmm | 20:28 |
juliusb | big gamble :) | 20:28 |
stekern | is it a big deal to boot off a livecd? :) | 20:29 |
juliusb | no not really but a bit embrassing :) | 20:29 |
juliusb | ummm busybox appears to work | 20:29 |
juliusb | i have it installed for somer eason | 20:29 |
juliusb | like, native busybox | 20:29 |
juliusb | ldd /sbin/busybox | 20:29 |
juliusb | not a dynamic executable | 20:29 |
juliusb | that sounds good | 20:29 |
stekern | yup, then you should be able to copy back with that | 20:31 |
juliusb | here goes | 20:31 |
* juliusb holds his breath | 20:31 | |
juliusb | luckily ldconfig is also statically linked | 20:32 |
juliusb | althoug, I guess it has to be | 20:32 |
juliusb | ok it appears when you put in a new loader, say from /new/lib/ld-2.14.so it then doesn't search places like /lib /usr/lib etc | 20:40 |
juliusb | so you have to put them into the LD_LIBRARY_PATH | 20:40 |
ConX | stekern: $or32-elf-gcc version or32-elf-gcc (OpenRISC 32-bit toolchain for or32-elf (built 20110410)) 4.5.1-or32-1.0rc4 | 21:22 |
juliusb | nup, couldn't get my trick to work in the end, chrome started, but then just hang on something | 21:56 |
juliusb | then all sorts of other system things started to break, like couldn't login anymore, weird behaviour from some tools | 21:57 |
juliusb | haha | 21:57 |
juliusb | sudo stopped working, for isntance | 21:57 |
juliusb | probably not what you want | 21:57 |
juliusb | :) | 21:57 |
ConX | stekern: it's ok now! it was my (syntax) fault | 23:06 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!