| --- Log opened Sun Sep 21 00:00:02 2014 | ||
| poke53282 | stekern: Do you know if l.trap should be handled like l.sys? | 01:06 |
|---|---|---|
| poke53282 | With the pc I mean. Should it point to the next instruction? | 01:06 |
| poke53282 | At the moment I guess not | 01:08 |
| poke53282 | according to or1ksim I am right | 01:38 |
| poke53282 | at some point the pc in the pt_regs structure in 5h3 k34n3l is added by 4. I don't know where this happens and why. | 04:47 |
| poke53282 | s/5h3 k34n3l/the kernel/ | 04:48 |
| poke53282 | This value should be identical to the epcr spr. | 04:49 |
| sb0_ | stekern, do GCC's __builtin_setjmp and __builtin_longjmp work for or1k? | 05:20 |
| sb0_ | and should we use those in misoc instead of the asm implementation? | 05:20 |
| stekern | sb0_: I don't think we implement those | 05:43 |
| sb0_ | hmm... and should I expect llvm.eh.sjlj.setjmp/longjmp to work? | 05:44 |
| sb0_ | "The buffer format and the overall functioning of [llvm.eh.sjlj.setjmp] is compatible with the GCC __builtin_setjmp implementation allowing code built with the clang and GCC to interoperate" ...and I actually need similar interoperability | 05:47 |
| poke53282 | http://pastie.org/9580496 | 05:49 |
| poke53282 | stekern: Is there a reason for the last line? | 05:50 |
| poke53282 | regs->pc += 4 | 05:50 |
| stekern | poke53282: that sounds like a signal problem | 05:50 |
| stekern | oh.. that I don't know | 05:50 |
| sb0_ | that's why people love ARM... and starting the 31337th open softcore won't address this issue | 05:52 |
| sb0_ | well, I'll have a look at it | 05:52 |
| poke53282 | is there a chance to see the history of this line in git | 05:52 |
| stekern | sb0_: I was answering to poke53282 | 05:52 |
| stekern | sb0_: if you don't use __builtin_setjmp, then there's of course no difference between how llvm and gcc use setjmp/longjmp | 05:53 |
| poke53282 | git log will do it | 05:53 |
| sb0_ | http://llvm.org/docs/ExceptionHandling.html#llvm-eh-sjlj-setjmp | 05:54 |
| sb0_ | it says that llvm.eh.sjlj.setjmp is compatible with __builtin_setjmp. doesn't say anything about custom asm implementations... | 05:54 |
| stekern | well, maybe builtin_setjmp is generic then? | 05:56 |
| stekern | grepping gcc, it seems only alpha, mips and pa do something special about it | 05:58 |
| stekern | poke53282: git blame works fairly well | 05:59 |
| poke53282 | Yes, I have found it. Nothing interesting. First commit from jonibo | 05:59 |
| stekern | poke53282: seems like a bug to me | 06:00 |
| poke53282 | well, I think this for returning from a a l.trap function. If you don't add 4, you will end up in a infinite loop. | 06:01 |
| poke53282 | of course the delayed insruction is not considered here. | 06:01 |
| poke53282 | So it's wrong anyhow. | 06:02 |
| stekern | well, you should end up in an infinite loop | 06:02 |
| stekern | if the l.trap is still there | 06:02 |
| poke53282 | Ok, then it's a bug. | 06:03 |
| stekern | ...but I don't know what the kernel expects with the trap | 06:05 |
| poke53282 | well, it's send the signal for the program. That's all. | 06:07 |
| poke53282 | unfortunately ltrace expects a single step debugging option. I won't implement in hardware. | 06:10 |
| poke53282 | So, the other option is to implement it in software. | 06:10 |
| poke53282 | Considering all the jumps and delayed instructions. | 06:11 |
| stekern | sb0_: looks like that's generic stuff, and that it works on or1k. I tested this: http://pastie.org/9580531 | 06:11 |
| poke53282 | This is already 50% of the cpu emulator | 06:11 |
| stekern | poke53282: oh, I think there was some single stepping code by juliusb in the kernel long ago, but jonas scraped that before upstreaming | 06:12 |
| sb0_ | yup, I'm looking at "void test(void *b) {__builtin_setjmp(b); }" and disassembling it | 06:12 |
| sb0_ | so far the asm code looks ok, but it is *not* compatible with the Embecosm implementation | 06:13 |
| stekern | no, but from the little I read about __builtin_setjmp/longjmp, I wouldn't expect it to be compatible with any libc setjmp/longjmp | 06:14 |
| poke53282 | Hmm, would be good to find this code. | 06:14 |
| poke53282 | Anyhow. ltrace works finally. Just two patches for the kernel, one for jor1k and two hundred code lines for ltrace. | 06:15 |
| poke53282 | And one full day :) | 06:15 |
| poke53282 | do you implement l.trap? | 06:15 |
| stekern | in mor1kx? | 06:15 |
| poke53282 | Yes | 06:15 |
| stekern | yes, that's how software breakpoints are used | 06:15 |
| sb0_ | why does the Embecosm *jmp save/restore all registers anyway? | 06:16 |
| sb0_ | well, most | 06:16 |
| stekern | sb0_: for no good reason | 06:16 |
| stekern | this is enough: http://git.musl-libc.org/cgit/musl/tree/src/setjmp/or1k/setjmp.s | 06:17 |
| sb0_ | already a lot, no? the __builtin_*jmp deals with fewer than that | 06:18 |
| stekern | maybe __builtin_*jmp utilises information about the reg usage in the context setjmp is called from? | 06:19 |
| sb0_ | http://pastebin.com/mjULACKu | 06:19 |
| stekern | the one that I pasted saves all the callee-saved registers | 06:21 |
| sb0_ | according to the llvm doc: "The single parameter is a pointer to a five word buffer in which the calling context is saved. The front end places the frame pointer in the first word, and the target implementation of this intrinsic should place the destination address for a llvm.eh.sjlj.longjmp in the second word. The following three words are available for use in a target-specific manner." | 06:22 |
| sb0_ | and I've seen elsewhere in GCC mailing lists that the __builtin_*jmp also expect a five-word buffer | 06:22 |
| stekern | yes, that's what I read too | 06:22 |
| stekern | we just have to make a test-case that uses up all the callee-saved regs and see what the __builtin_*jmps do with that ;) | 06:23 |
| stekern | I mean, a test-case that clobbers the callee-saved regs | 06:24 |
| stekern | poke53282: http://git.openrisc.net/cgit.cgi/jonas/linux/commit/?id=018469300c46bc37ebb5997bf73e6437fa16c329 | 06:32 |
| poke53282 | looks like, this is what I need. Today implemented a few of those features which were missing. | 06:36 |
| poke53282 | I bookmark this patch | 06:36 |
| poke53282 | I would also say, those patches are necessary for a native gdb | 06:45 |
| stekern | yes | 06:52 |
| stekern | hmmm, I have a fun thing happening in the kernel now... void f0(void) { printk("f0\n"; } void f1(void) { printk("f1\n"); f0(); } only prints 'f1' | 06:54 |
| poke53282 | strange | 06:56 |
| stekern | this is the actual code: http://pastie.org/9580589 | 07:09 |
| stekern | disasm gives: | 07:09 |
| stekern | c0323688: 15 00 00 22 l.nop 0x22 | 07:09 |
| stekern | c032368c: 15 00 00 23 l.nop 0x23 | 07:09 |
| stekern | must be another dma_request_slave_channel_reason() that get used | 07:10 |
| stekern | maybe some CONFIG knob that is needed for it to get compiled in | 07:10 |
| stekern | instead of some stub version | 07:11 |
| poke53282 | Is the whole code removed? | 07:13 |
| poke53282 | or only the function in between. I think this is what you mean. | 07:14 |
| poke53282 | Yes, looks like you have stub function there. | 07:14 |
| stekern | yup: http://lxr.free-electrons.com/source/include/linux/dmaengine.h#L1061 | 07:15 |
| poke53282 | I have decided to build a tiny sound card driver from scratch. One which sends the buffer and size to a register and the rest is done outside. | 07:21 |
| poke53282 | Otherwise I don't think that I can solve the issues I have | 07:22 |
| stekern | what are the issues you are having? | 07:23 |
| poke53282 | I choosed one driver which had pio as an option. | 07:23 |
| poke53282 | But I guess this was never really tested. | 07:23 |
| poke53282 | And I would need 1000 interrupts per second | 07:24 |
| poke53282 | around | 07:24 |
| poke53282 | So, the this didn't work. | 07:24 |
| poke53282 | But while trying to correct I issues I learned enough to understand everything important. | 07:25 |
| poke53282 | So I will take the driver and remove everything unimportant. | 07:27 |
| poke53282 | My main problem is the timing | 07:27 |
| poke53282 | and the communicating with the different components. | 07:27 |
| poke53282 | good sound emulating is always difficult. | 07:28 |
| poke53282 | and if I have my own driver with my own parameters will help a lot. | 07:29 |
| poke53282 | mount /dev/bed /home/bed; && mv -f poke /home/bed && sleep 28800 | 07:36 |
| stekern | =) | 07:39 |
| sb0 | stekern, how can one ensure that the mor1kx store buffer is empty? | 10:22 |
| sb0 | I've seen weird behaviour when dynamically loaded code, that mysteriously disappeared when CRCing the code before executing it. I suspect the store buffer might have something to do with that... | 10:23 |
| stekern | sb0: l.msync *should* ensure that, but I haven't fixed that yet. You can do a dummy load to achieve the same result though | 10:51 |
| sb0 | to any address? | 10:53 |
| stekern | yes | 10:54 |
| PaulfraOSAA | Does anybody know what happend to opencores? | 13:39 |
| PaulfraOSAA | Did they get a ceice and decist from sony or something? | 13:39 |
| PaulfraOSAA | Cease* | 14:38 |
| sb0 | unsurprisingly enough, setjmp/longjmp are buggy | 16:15 |
| sb0 | LONG LIVE ARM | 16:15 |
| sb0 | let's try the musl stuff ... | 16:16 |
| PaulfraOSAA | What is the verilog equivalent to open? I need some signals to not be attached | 16:45 |
| stekern | PaulfraOSAA: just () | 16:46 |
| PaulfraOSAA | ok, thanks. I tried it, but it still failed. Turns out i set the inputs to open too _doh_ | 16:47 |
| PaulfraOSAA | YAY! It synthesizes :) I've added a module to an or1k core :D | 16:56 |
| PaulfraOSAA | Now to make it output stuff | 16:56 |
| stekern | sb0: in what way buggy (and in what way will ARM not be, if all is generic stuff anyway?) | 17:07 |
| PaulfraOSAA | Added lots of stuff to http://osaa.dk/wiki/index.php/OpenRISC please read and comment if you have a mo' next up is doing assembly and debugging | 17:11 |
| poke53282 | Ok, I created a reposotory with my changes to ltrace. https://github.com/s-macke/ltrace/tree/openrisc . When I have solved two or three problems, I can give the patches to the author of ltrace. | 19:22 |
| olofk | stekern: I think I misunderstood you regarding the wb_intercon stuff | 19:49 |
| olofk | But that looks fine with me | 19:51 |
| olofk | If I have understood things right, wb_intercon.conf would still decide the maximum number of cores | 19:53 |
| stekern | olofk: yes, the max num of cores is still determined from wb_intercon.conf | 20:16 |
| stekern | poke53282: cool! | 20:17 |
| olofk | stekern: I say go for it then. | 20:40 |
| --- Log closed Mon Sep 22 00:00:04 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!