| --- Log opened Wed Sep 03 00:00:35 2014 | ||
| sb0 | stekern, it works, though the performance is rather low due to the CPU doing everything (preamble, FCS, etc.) | 01:51 |
|---|---|---|
| sb0 | if you can live with a low-bandwidth network connection (a few hundred kilobytes/s) that uses a lot of CPU time, that's fine | 01:53 |
| stekern | hmm... not sure I can live with that ;) | 02:43 |
| stekern | adding preamble and FCS doesn't sound hard though | 02:45 |
| poke53281 | I want to compile the descent 1 remake. Almost no problem during compiling. But it ends with a segmentation fault when I want to run it. Before it reaches the main routine. strace ends after loading the libraries. Last command: set_tid_address(0x300c1824)=68 | 02:53 |
| poke53281 | http://pastie.org/9523029 | 02:57 |
| poke53281 | I guess the first test would be a static compile | 02:58 |
| stekern | poke53281: to debug segfaults, I usually run my kernel with some debug printks sprinkled at the places where sigsegv is sent | 02:58 |
| stekern | e.g.: http://pastie.org/9523033 | 03:00 |
| poke53281 | a working gdb would also help I guess. What is the easiest way to get address of this fault? | 03:00 |
| poke53281 | thanks | 03:01 |
| poke53281 | Will try it | 03:01 |
| stekern | but there are more places from where sigsegv can be sent | 03:01 |
| stekern | most come from do_fault though, so try with that first | 03:03 |
| stekern | I couldn't refrain myself from porting the old mandelbrot code to SDL yesterday, it works, but oh so slow ;) | 03:04 |
| stekern | http://pastie.org/9523041 | 03:06 |
| poke53281 | don't use double | 03:25 |
| poke53281 | and use -mhard-float | 03:25 |
| stekern | yes and no | 03:26 |
| poke53281 | try an integer based mandelbrot | 03:26 |
| poke53281 | this is possible | 03:26 |
| poke53281 | fixed-comma | 03:26 |
| stekern | I know, I just wanted to preserve my antique code ;) | 03:26 |
| stekern | but I can't use hard-float | 03:26 |
| stekern | I don't have an FPU | 03:27 |
| poke53281 | I expected, that you would say this. | 03:27 |
| poke53281 | then parallelize it with 64 cores. Use the biggest FPGA you can find ;) | 03:28 |
| stekern | well, there's the one bandvig is working on, so in theory I could | 03:28 |
| stekern | but, I think using fixed point math would still be faster | 03:29 |
| poke53281 | probably | 03:29 |
| poke53281 | like in the good old days. | 03:30 |
| stekern | it runs fast enough on my x86_64 workstation though ;) | 03:30 |
| poke53281 | If you think it runs too fast try to implement using libmpfr and use 1000 digits accuracy. | 03:33 |
| poke53281 | Then we will see which one is faster. | 03:33 |
| stekern | =P | 03:35 |
| stekern | poke53281: did you have some X building recipes btw? | 03:35 |
| poke53281 | yes, of course. Wait | 03:36 |
| poke53281 | http://jor1k.com/or1k-toolchain.tar.bz2 | 03:49 |
| poke53281 | http://jor1k.com/downloads/ | 03:49 |
| poke53281 | http://jor1k.com/packages/ | 03:49 |
| poke53281 | This is everything you need. | 03:49 |
| poke53281 | I you don't want to compile just use my .tar.bz2 packages | 03:50 |
| poke53281 | please send every legimitate complaint to /dev/zero | 03:51 |
| poke53281 | construxtive criticism however to the chat | 03:52 |
| poke53281 | Today I would the whole scripts with bash. An not with make. What was I thinking. | 03:53 |
| poke53281 | Sometimes I spread a -mhard-float into the Makefiles. | 03:55 |
| stekern | thanks | 04:02 |
| poke53281 | stekern: http://pastie.org/9523143# | 04:43 |
| poke53281 | pc is zero | 04:44 |
| poke53281 | but I can start with GPR09 | 04:46 |
| poke53281 | and I can check for this pc in the emulator | 04:47 |
| stekern | yeah, and you can of course add some debug stuff to jor1k to track for pc = 0 | 04:47 |
| stekern | and save some state in a ring buffer | 04:47 |
| poke53281 | this was the last point I mentioned :) | 04:48 |
| stekern | right, we were typing at the same time ;) | 04:48 |
| poke53281 | sigh, according to ldd there is nothing at the address of gpr09 | 04:50 |
| stekern | worth noting might be the segfault I had with scummvm 1.7 | 04:55 |
| stekern | might or might not be related | 04:55 |
| poke53281 | 0x30179AE0 | 04:55 |
| poke53281 | again, nothing loaded at this address | 04:57 |
| poke53281 | hmm, maybe this is already part of the error | 04:58 |
| stekern | what is the output of ldd? | 04:59 |
| poke53281 | one second | 04:59 |
| poke53281 | /lib/ld-musl-or1k.so.1 (0x8000000) | 05:01 |
| poke53281 | libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x30000000) | 05:01 |
| poke53281 | libphysfs.so.1 => /usr/lib/libphysfs.so.1 (0x3007c000) | 05:01 |
| poke53281 | libc.so => /lib/ld-musl-or1k.so.1 (0x8000000) | 05:01 |
| poke53281 | libts-1.0.so.0 => /usr/lib/libts-1.0.so.0 (0x300b0000) | 05:01 |
| poke53281 | libz.so.1 => /usr/lib/libz.so.1 (0x300b4000) | 05:01 |
| stekern | hmm... | 05:07 |
| poke53281 | libz end address should 300D675C | 05:08 |
| poke53281 | I think musl is mapping something there. | 05:09 |
| poke53281 | probably I should print the memory mapping during that segfault too. | 05:09 |
| poke53281 | every library is independently tested with other programs. Also libphys | 05:11 |
| poke53281 | libphysfs | 05:11 |
| poke53281 | stekern: the ringbuffer gives me http://pastie.org/9523247 | 05:56 |
| poke53281 | only every fourth pc printed | 05:56 |
| poke53281 | so the last known position is in the function BlitNtoN in libSDL. | 06:03 |
| stekern | is that the 0x30024FF0? | 06:12 |
| poke53281 | Yes | 06:13 |
| stekern | where should it jump from there? | 06:13 |
| poke53281 | http://pastie.org/9523318 | 06:14 |
| poke53281 | it's actually 24FF8 | 06:14 |
| stekern | that doesn't make sense | 06:16 |
| poke53281 | I know | 06:16 |
| stekern | can you dump epcr when the itlb miss hits? | 06:19 |
| poke53281 | qemu-user also stops | 06:23 |
| poke53281 | it stops somewhere slightly above the libSDL binary | 06:30 |
| olofk | there were no problems enabling gdb and sim when building binutils | 06:32 |
| olofk | And I made sure to not have any or1k-elf- stuff in my path when building it | 06:33 |
| poke53281 | stekern: http://pastie.org/9523357 | 06:35 |
| poke53281 | I will also print the opcode now | 06:35 |
| poke53281 | add this addres libc.so is mapped and not libSDL | 06:51 |
| poke53281 | ldd is really really wrong | 06:52 |
| poke53281 | stekern: http://pastie.org/9523399 | 06:56 |
| poke53281 | do_init_fini of libc | 06:57 |
| poke53281 | I don't have a clue what's at 0x30179768 | 06:58 |
| stekern | olofk: but then you are building binutils from or1k-src? | 06:58 |
| stekern | poke53281: ok, that starts to make more sense at least | 06:59 |
| poke53281 | stekern: what is the section .plt ? | 07:15 |
| stekern | what are you asking about it? | 07:20 |
| poke53281 | http://pastie.org/9523429 | 07:20 |
| poke53281 | found the crash position | 07:20 |
| poke53281 | in libz.so | 07:21 |
| stekern | is it the jump to frame_dummy or to __do_global_ctors_aux? | 07:23 |
| poke53281 | http://jor1k.com/libz.as | 07:24 |
| poke53281 | it's the jump in .plt | 07:24 |
| poke53281 | in section .plt and function <.plt> | 07:24 |
| poke53281 | Have to sleep soon. You can find the binary in the libz.tar.bz2 in the packages directory I send you a few hours ago if you want to investigate it further. | 07:26 |
| poke53281 | But it seems, that this is a real error. | 07:26 |
| poke53281 | real severe error. | 07:26 |
| poke53281 | the libc is in musl.tar.bz2 | 07:27 |
| stekern | what do you mean by the 'jump in .plt'? | 07:28 |
| stekern | afaics the calls from _init doesn't go through the plt? | 07:29 |
| poke53281 | sorry, it's late | 07:32 |
| poke53281 | one moment | 07:32 |
| stekern | yeah, no problem, don't let me keep you up ;) | 07:32 |
| poke53281 | but it looks correct | 07:35 |
| poke53281 | look at the disassembly | 07:37 |
| poke53281 | he jumps to <_init+0x36c> | 07:37 |
| poke53281 | which is in <.plt> and not in <_init> | 07:37 |
| stekern | here?: http://pastie.org/9523247 | 07:39 |
| poke53281 | je jumps at pc:0x30179DCC, which is 0x1DCC in the disassembly. | 07:39 |
| stekern | bah | 07:39 |
| stekern | yeah, so *that* call goes through the plt | 07:39 |
| poke53281 | http://pastie.org/9523429 | 07:39 |
| poke53281 | this one I posted before | 07:39 |
| stekern | I was only looking at the frame_dummy and __do_global_ctors_aux calls | 07:40 |
| stekern | yes, I was suppose to paste this from that: "pc:0x30179DCC epcr:0x30179768 ins:0x07FFFF42" master.js:191 l.jal 1ad4 <_init+0x36c> | 07:41 |
| poke53281 | the l.lwz gives probably a zero value and then he tried to zero | 07:41 |
| poke53281 | to jump to zero | 07:41 |
| stekern | so what function should it jump to from that plt entry? | 07:41 |
| poke53281 | don't know | 07:41 |
| poke53281 | I don't even know what the plt is. I am just telling you what's written here :) | 07:42 |
| olofk | stekern: Yes, building from or1k-src. The point of this exercise (except for learning what the hell is really going on) is so that we can clean up the build instructions a bit | 07:43 |
| stekern | aha, plt is the procedure linkage table. position independent calls go through that | 07:44 |
| stekern | olofk: but we "shouldn't" build binutils from that, but from upstream | 07:44 |
| olofk | stekern: Yes I know, but at least splitting out newlib is a good first step | 07:45 |
| stekern | right | 07:45 |
| olofk | And once gdb is upstreamed, we will probably do it like this anyway | 07:45 |
| olofk | And if we don't care about gdb, we can build from upstream binutils | 07:46 |
| olofk | (given that newlib is split out) | 07:46 |
| stekern | poke53281: I can take a look at it, but just as a reference, you can get the function that is getting called by looking at the offset to r16 in at 0x1ad4 and then use that offset to look up the function in the GOT (r16 should point to that) | 07:47 |
| olofk | I thought about rebasing our newlib port to upstream newlib, but I'm a bit scared of their CVS repo | 07:47 |
| stekern | poke53281: you should objdump with -RD to get more info | 07:48 |
| olofk | Aha. There's a git repo as well now | 07:48 |
| poke53281 | stekern: Sorry, too late. But the first thing you can try is check the output from for an arbitrary binary. | 07:50 |
| poke53281 | if ldd is correctly mapped to 0x80000000 or 0x30000000 | 07:50 |
| poke53281 | I mean if libc is correctly mapped | 07:50 |
| stekern | yeah, go to bed ;) as I said, I can objdump libz myself and look it up, I'm just mentioning it for future reference | 07:51 |
| poke53281 | last message for today: registers right before the jump to zero. r12 is indeed zero | 07:55 |
| poke53281 | " r4: 0x3019A2A4 r5: 0x30179768 r6: 0x7FDC1CCC r7: 0x7FDC1D20" master.js:191 | 07:55 |
| poke53281 | " r8: 0x7FDC1D38 r9: 0x30179DD4 r10: 0x300C18C8 r11: 0x000001EC" master.js:191 | 07:55 |
| poke53281 | " r12: 0x00000000 r13: 0x00000000 r14: 0x7FDC1E44 r15: 0x0000807E" master.js:191 | 07:55 |
| poke53281 | " r16: 0x3019A1BC r17: 0xFFFFFFF9 r18: 0x00000000 r19: 0x00008079" master.js:191 | 07:55 |
| poke53281 | " r20: 0x00000000 r21: 0x30172234 r22: 0x300C3280 r23: 0x00000000" master.js:191 | 07:55 |
| poke53281 | " r24: 0x300C1970 r25: 0x00000000 r26: 0x300C1964 r27: 0xFFFFFFF9" master.js:191 | 07:55 |
| poke53281 | " r28: 0x300C196C r29: 0x00008079 r30: 0x00000000 r31: 0x00000010" | 07:55 |
| olofk | So, should I use musl, uClibc or glibc for my linux toolchain? | 09:10 |
| olofk | Can is any of them also able to build linux now? I'm trying to cut down on my toolchain building | 09:11 |
| olofk | s/Can/and | 09:19 |
| stekern | none of the libc's are involved when you build Linux | 09:22 |
| stekern | but you should be able to build Linux with the gcc from any of them | 09:22 |
| stekern | poke53281: looks like it's __register_frame_info that it tries to call at the place where it fails | 09:38 |
| stekern | and the got pointer (r16) in your register dump looks right, so somehow the dynloader hasn't resolved that reloc | 09:59 |
| olofk | wallento: Is your or1k-newlib repo in good enough shape to be used? | 10:12 |
| olofk | hmmm.. looks like it could need some more stuff | 10:16 |
| olofk | Doesn't CROSS_COMPILER= work anymore for building the kernel? | 10:54 |
| olofk | ah.. maybe I forgot a make clean after switching branches | 10:58 |
| wallento | olofk: nope, I just started this | 11:01 |
| wallento | i hope end of the week | 11:01 |
| olofk | wallento: But it's a complete reimplementation, right? | 11:02 |
| olofk | The reason why I'm asking is that we probably don't want to send the current GPLv3-licensed port upstream | 11:02 |
| wallento | i am still not sure how the build tree stuff works | 11:02 |
| wallento | not a complete, but only those part where the authors are not fine with BSD | 11:02 |
| wallento | they don't accept, we have already been there | 11:02 |
| olofk | Exactly what I was going to ask :) | 11:02 |
| wallento | talked with julius, stefan and jeremy | 11:03 |
| olofk | perfect | 11:03 |
| wallento | think I missed you | 11:03 |
| olofk | I miss you too :) | 11:03 |
| wallento | ;) | 11:03 |
| olofk | I think that I only submitted ordb2a.S and I'm fine with another license for that | 11:03 |
| olofk | The D&R license is pretty good | 11:14 |
| stekern | I (seriously) like wtfpl best | 11:30 |
| maxpaln | BTW, I was asked to do some rough benchmarking of the new processor vs the old one. One of them was the boot time for Linux - it has dropped from some 55 seconds (with OR1200) to 9 secocds (with MOR1KX) :-) That's a nice reduction!! | 12:22 |
| stekern | there's no secret that or1200 is a lot slower than mor1kx, especially when MMUs are turned on. that's more difference than I'd expected though | 12:47 |
| maxpaln | well, in slight fairness to the OR1200, I wasn't able to run it with cache'ing (because of the bug I found) and the clock rate was slower, but the OR1200 clock rate was as fast as I could get it. So the improvement is from a number of factors - the 55 seconds was as good as I could get the OR1200, 9 seconds is probably as good as I can get the MOR1KX. | 12:50 |
| maxpaln | short of putting it in one of our instant-on devices - then it would probably be 2-3 seconds. | 12:51 |
| hesham | Is l.csync instruction supported? I am trying to use it from asm volatile statement and I got "unrecognized form of instruction `l.csync'" assembler error | 13:04 |
| hesham | The same goes for l.msync | 13:04 |
| stekern | hesham: they are supported in upstream binutils at least | 14:17 |
| stekern | and, prior to this: https://github.com/openrisc/mor1kx/commit/2e695ee7f57976af8a7732acf1e3e52d7f671a48 | 14:18 |
| stekern | mor1kx would cause an illegal instruction on it, instead of treating it as a nop | 14:19 |
| stekern | l.csync will still cause an illegal instruction unless you explicitly "enable" it (there's no real logic behind it) | 14:20 |
| stekern | strictly speaking, even though load/stores are ordered, I should add proper support for l.msync | 14:24 |
| sb0 | stekern, btw, have you tried porting the old milkymist soc drivers to misoc/mor1kx? | 14:25 |
| stekern | for the case where where instruction mem is written and you want to ensure that the store has finished before you run the code | 14:26 |
| stekern | sb0: what drivers are you speaking about? Linux drivers? | 14:28 |
| sb0 | yes | 14:29 |
| sb0 | for uart and timer | 14:29 |
| stekern | no, but it's something I want to do at some time | 14:29 |
| stekern | let's make that s/want/intend ;) | 14:30 |
| stekern | the timer is actually relevant to what I'm currently doing, removing the hard dependency on the built-in or1k timer | 14:33 |
| maxpaln | now that my HW is stable, I'm reviewing the Linux config. I have noticed that the interrupts I have assigned in the DTS might have become out of date - I only have a few entries in there so it probably isn't that big a deal right now. But as I add a few more I want to make sure the interrupts are correctly assigned. | 15:01 |
| maxpaln | What interrupt should assigned to the pic? | 15:01 |
| maxpaln | it is currently assigned to interrupt 1 - which from memory used to be an unassigned non-maskable interrupt in orpsoc_top | 15:02 |
| maxpaln | ah, my mistake - the PIC doesnb't have an interrupts entry. It has an interrupt-cells entry. Very different!! | 15:18 |
| --- Log closed Wed Sep 03 16:04:41 2014 | ||
| --- Log opened Wed Sep 03 16:05:15 2014 | ||
| -!- Irssi: #openrisc: Total of 42 nicks [0 ops, 0 halfops, 0 voices, 42 normal] | 16:05 | |
| -!- Irssi: Join to #openrisc was synced in 23 secs | 16:05 | |
| poke53281 | stekern: the value 0x0 to this address is written by the function do_relocs. | 16:18 |
| poke53281 | case REL_SYM_OR_REL | 16:19 |
| -!- rah_ is now known as rah | 16:20 | |
| stekern | poke53281: yes | 16:22 |
| poke53281 | you know? | 16:23 |
| stekern | yes: SJK DEBUG: Relocating /usr/lib/libz.so.1: __register_frame_info: base = 3016e000, def.sym = 0, 3019026c <= 0 | 16:24 |
| poke53281 | Ok, so you can reproduce the bug. | 16:25 |
| stekern | yes, I haven't got my head fully around it though | 16:25 |
| stekern | __register_frame_info is defined in libgcc_s.so, *but* glibc defines that as well (musl don't) | 16:26 |
| poke53281 | with my binary or also yours. Note that we use a daily snapshot of binutils | 16:26 |
| stekern | I don't think binutils is related here | 16:27 |
| stekern | or at least not on that level that there would be a difference between the daily snapshots | 16:28 |
| stekern | but, to answer your question, with your binary | 16:28 |
| poke53281 | Strange is, that libz is one of the most linked libraries after libc. And so far, all other programs work. | 16:29 |
| stekern | oh... actually, maybe it's not that __register_frame_info resolves to 0 there that is the error | 16:31 |
| stekern | wait, I'll paste my full debug printout to show what I'm speaking about | 16:32 |
| poke53281 | note that it doesn't work in qemu either. So probably it has nothing to do with the kernel and the emulator. | 16:33 |
| stekern | no, it doesn't | 16:34 |
| stekern | http://pastie.org/pastes/9524635/text | 16:34 |
| stekern | notice that there are 2 __register_frame_info there | 16:34 |
| stekern | and this is the output of readelf -rd: http://pastie.org/9524639 | 16:36 |
| stekern | the one that resolves to zero is the R_OR1K_JMP_SLOT and the one that resolves to 4464 is the R_OR1K_GLOB_DAT | 16:36 |
| maxpaln | feeling stupid. Trying to mount the SPI flash in Linux - I keep getting told that my mount command contains an invalid argument!! | 16:37 |
| stekern | now let's take a look at libgcc's crtstuff to find out why those two are there | 16:37 |
| maxpaln | I am wondering if it is complaining about the jffs2 FSTYPE - does this need to be included in the Linux lernel, I have looked and can;t find a specific entry for it.... | 16:38 |
| stekern | https://github.com/openrisc/or1k-gcc/blob/or1k/libgcc/crtstuff.c#L457 | 16:38 |
| stekern | so, the 'if (__register_frame_info)' is the R_OR1K_GLOB_DAT and the '__register_frame_info (__EH_FRAME_BEGIN__, &object);' is the R_OR1K_JMP_SLOT | 16:39 |
| stekern | why doesn't that R_OR1K_GLOB_DAT resolve to 0? | 16:39 |
| poke53281 | don't know | 16:41 |
| stekern | maxpaln: what about JFFS2_FS? | 16:41 |
| maxpaln | stekern: maybe you're right - this moved me to: | 16:42 |
| maxpaln | # mount -t JFFS2_FS /dev/mtd2 /mnt/spi0 | 16:42 |
| maxpaln | mount: mounting /dev/mtd2 on /mnt/spi0 failed: No such device | 16:42 |
| maxpaln | I am confused by this one - I have just run a flash_eraseall on the /dev/mtd2 partition! hmmm..... | 16:43 |
| stekern | maxpaln: I meant in the kernel config | 16:44 |
| maxpaln | LOL - in which case the new error message from the command prompt is really odd!! | 16:44 |
| maxpaln | I#ll check the kernel config... | 16:44 |
| maxpaln | ok, JFFS2 is set: CONFIG_JFFS2_FS=y | 16:45 |
| stekern | poke53281: yeah, me neither... but I think finding that out is the right track | 16:47 |
| maxpaln | hmmm, confused - I am using the same commands as the last time I was at this point (on our eval board some 6 months ago - wow, what a ride to here!) - but this 'invalid argument' has me confused. | 16:53 |
| poke53281 | Hmm, the libz.so from sabotage linux doesn't even have the register_frame entry | 16:54 |
| maxpaln | both the directory I am pointing at and the device I am pointing at exist - | 16:54 |
| maxpaln | # mount -t jffs2 /dev/mtd2 /mnt/spi0 | 16:54 |
| maxpaln | mount: mounting /dev/mtd2 on /mnt/spi0 failed: Invalid argument | 16:54 |
| poke53281 | But is has _Jv_RegisterClasses | 16:55 |
| poke53281 | and the entries are at the same places if I look at the readelf output | 16:56 |
| poke53281 | http://pastie.org/9524667# | 16:57 |
| poke53281 | stekern: I can give you any output you want before the jump. Just tell me. | 17:02 |
| poke53281 | maxpaln: Is there no checkdisk utility for jffs2. Maybe your image is broken | 17:08 |
| maxpaln | hmmm, all I've done is a flash_eraseall - no image. | 17:09 |
| maxpaln | the erase seems to work correctly: | 17:09 |
| maxpaln | # flash_eraseall -j /dev/mtd2 | 17:09 |
| maxpaln | Erasing 64 Kibyte @ 2d0000 - 100% complete.Cleanmarker written at 2c0000. | 17:09 |
| poke53281 | aehmm, mkfs.jffs2 before mounting maybe? | 17:09 |
| maxpaln | I don't have the mkfs.jffs2 command - | 17:09 |
| maxpaln | adding the mtd-utils (or whichever package adds it) was next on my list | 17:10 |
| maxpaln | but I have definitely been able to mount the SPI Flash using just the mount command before - | 17:10 |
| poke53281 | but if it is just erased, how should the mount work. jffs2 is not reckognized then. | 17:11 |
| maxpaln | ok - I thought the -j option to the flash_eraseall would format for jffs2 | 17:11 |
| maxpaln | is that wrong? | 17:11 |
| maxpaln | or perhaps there is another step...I don't remember having another step (if on;y I'd written down the commands!!!) | 17:12 |
| poke53281 | I have never used it. Don't know anything about the -j option. | 17:13 |
| stekern | poke53281: hmmm... interesting. but I don't know if that's of essence. | 17:13 |
| poke53281 | maxpaln: I would suggest to install those mtd tools and try to use the mkfs.jffs2 program. | 17:15 |
| maxpaln | yeah, good approach. | 17:15 |
| maxpaln | one for tomorrow now I think. Thanks all | 17:16 |
| poke53281 | stekern: Just try to narrow down the problem. | 17:17 |
| stekern | poke53281: because, __register_frame_info is declared as a weak reference in crtstuff. which means that it should resolve to 0 if nothing defines it | 17:20 |
| stekern | so, to me it seems like that it doesn't resolve to zero would be the problem | 17:22 |
| stekern | maybe x86_64 is able to completely remove that reloc in that case? | 17:23 |
| poke53281 | simple libz programs work. Maybe it would make sense to run your musl debug version here directly on this binary. | 17:57 |
| poke53281 | some other part must interfere here. | 17:58 |
| stekern | do "simple libz programs" pull in libgcc_s.so? | 17:59 |
| poke53281 | tried "gcc prog.c -lgcc_s -lz" and "gcc prog.c -lz -lgcc_s" | 18:01 |
| poke53281 | both link according to ldd and work without problems | 18:02 |
| stekern | this is the debug print I've added http://pastie.org/9524799 | 18:02 |
| stekern | yes, if they pull in libgcc_s, then they will probably work | 18:02 |
| poke53281 | I linked a program so that the ldd output is exactly the same. The program runs. | 18:07 |
| stekern | can you give me that program? | 18:08 |
| poke53281 | http://pastie.org/9524814 | 18:10 |
| poke53281 | you mean the binary | 18:10 |
| stekern | yes, but I can try compiling that too ;) | 18:11 |
| dalias | i'm just jumping in this conv... | 18:11 |
| dalias | but gratuitous libgcc_s.so is usually a toolchain bug in ld | 18:11 |
| poke53281 | stekern: jor1k.com/a.out | 18:13 |
| poke53281 | the ldd output is the same as for d1x-rebirth | 18:14 |
| poke53281 | dalias: Something maybe not related to this bug here: the ldd output differs from the real mapping. ldd tells me that libc and ls-musl-.... is mapped to 0x80000000. But actually it is mapped to 0x30000000 | 18:15 |
| stekern | dalias: I was counting on that you would have some valuable info on the subject, but I consider asking you before trying to investigate ourselfs cheating ;) | 18:15 |
| dalias | iirc --as-needed is supposed to be passed to the linker for libgcc_s | 18:16 |
| dalias | and the linker is supposed to omit linking it if it's not _needed_ to satisfy undefined, _non-weak_ symbol references | 18:16 |
| dalias | lots of toolchains historically had bugs where they would pull in libgcc_s even if it wasn't needed if it was satisfying weak symbol references | 18:16 |
| stekern | dalias: to sum up, this is the code that cause the reloc: https://github.com/openrisc/or1k-gcc/blob/or1k/libgcc/crtstuff.c#L457 | 18:18 |
| stekern | I would assume that the case where we fail is when libgcc_s is *not* needed | 18:19 |
| poke53281 | stekern: Now I try to link d1x-rebirth with libgcc_s | 18:19 |
| stekern | so the weak reference is not satisfied (which would then be correct) | 18:20 |
| stekern | but the problem is that when the relocs for the code in frame_dummy is done, the 'if (__register_frame_info)' does not resolve to 0 | 18:21 |
| poke53281 | stekern: Indeed, it works | 18:23 |
| poke53281 | ! | 18:23 |
| poke53281 | d1x-rebirth starts now | 18:24 |
| -!- knz_ is now known as knz | 18:24 | |
| stekern | there's more to it... with your a.out, the R_OR1K_GLOB_DAT __register_frame_info get resolved to 0 | 18:27 |
| poke53281 | stekern: This is the final linking process: http://pastie.org/9524855 | 18:35 |
| poke53281 | Nothing unusal I would say. | 18:35 |
| stekern | but without the -lgcc_s normally, right? | 18:36 |
| poke53281 | yes | 18:36 |
| poke53281 | I included -lgcc_s five minutes ago. | 18:37 |
| stekern | right | 18:37 |
| poke53281 | Now I get a segmentation fault because he is out of memory :) Descent 1 was supposed to run with 4MB. And now not even 32MB is enough. Cruel world. | 18:38 |
| poke53281 | hmm, he tries to map 770MB. | 19:23 |
| poke53281 | of course an unaligned access | 19:26 |
| olofk | USB passthrough in Virtualbox is really cool. I can run openocd against my de0_nano from inside a VM | 19:31 |
| ysionneau | I usually flash my fpga boards through virtualbox on my macbook | 19:36 |
| poke53281 | does virtualbox finally support usb 2.0? | 19:37 |
| olofk | poke53281: Yes, so now we are waiting for USB passthrough in jor1k as well ;) | 19:41 |
| poke53281 | If the development of the browsers go on like in the last few years they will implement such a feature in html 6 or 7. | 19:45 |
| poke53281 | so that I can use it | 19:45 |
| poke53281 | It looks like d1x-rebirth need a lot of patches in order to solve the alignment issue. | 20:07 |
| stekern | poke53281: where is it coming from? | 20:28 |
| poke53281 | Basically from everywhere. Have fixed two positions, got a third one. | 20:33 |
| poke53281 | main/polyobj.c | 20:33 |
| poke53281 | int pof_read_int() | 20:33 |
| poke53281 | i = *((int *) &bufp[Pof_addr]); | 20:33 |
| poke53281 | that's the first one. | 20:33 |
| poke53281 | people have problems to run it on arm devices too. | 20:33 |
| poke53281 | it puts pointers of packed structs directly into the loaded file. And then swaps integers around. | 20:35 |
| poke53281 | So, without a complete rewrite of some loading functions it won't work. | 20:35 |
| poke53281 | nothing you can do I would say. | 20:38 |
| stekern | mmm, fun... | 20:42 |
| olofk | I should get me one of the UART adapters with short cables for each of the pins so I don't have to change the pin mapping for every damn adapter | 20:44 |
| poke53281 | blueCmd: How do I find if debian uses any patches for a program? Where are the build-scripts they are using? | 21:42 |
| olofk | Oh windows. How I forgot what a shitty fucking OS you are | 21:43 |
| olofk | To find out if a .exe is 32 or 64 bit they recommend using GNU File :) | 21:50 |
| poke53281 | It's still amazing that the most often used string you can find in Windows is "This program cannot be run in DOS mode" | 21:53 |
| poke53281 | It's in every executable in the header. | 21:53 |
| poke53281 | .dll .sys .exe, ... | 21:53 |
| olofk | haha | 21:53 |
| olofk | What a waste of bytes | 21:54 |
| dalias | :) | 21:57 |
| --- Log closed Thu Sep 04 00:00:37 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!