| _franck_ | never seens that :( | 00:01 |
|---|---|---|
| _franck_ | are you trying to compile for or1k-*-linux* target ? | 00:04 |
| _franck_ | because I didn't try that and I don't think it'll work yet | 00:05 |
| blueCmd | _franck_: yeah | 00:05 |
| blueCmd | TARGET=or1k-linux | 00:06 |
| _franck_ | if you want to work on it I have some information. Jonas Bonn start something | 00:07 |
| _franck_ | before I continue working on gdb I'd like to run this f*!?ing testsuite | 00:10 |
| _franck_ | blueCmd: you have no chance to compile gdbserver, we don't have or1k-linux-tdec.c .... | 00:20 |
| blueCmd | _franck_: aha, I just want to have something to look at why I managed to corrupt my frames | 00:22 |
| blueCmd | I don't think I need gdbserver for that - not sure. | 00:22 |
| blueCmd | qemu has some interface to talk to gdb if I'm not misstaken | 00:22 |
| _franck_ | yeah, I'm mixing things because I'm don't know gdb very well :) however, for linux target, we need or1k-linux-tdec.c | 00:24 |
| blueCmd | _franck_: fair enough | 00:25 |
| blueCmd | _franck_: out of curiosity - are you using it with newlib or something like that? | 00:25 |
| _franck_ | I'm just using gdb to debug OpenOCD :) I just writing some asm program, download them to the target and check if openocd + opencores tap + debug unit are working | 00:27 |
| _franck_ | or sometimes I use barebox as a test program which is not linked to newlib | 00:28 |
| _franck_ | barebox is like uboot | 00:28 |
| blueCmd | _franck_: aha! cool | 00:43 |
| blueCmd | I didn't even know you could do that - nice! | 00:43 |
| stekern | blueCmd: if you want to debug the kernel (i.e. not user space) you should be able to use the elf-gdb | 06:45 |
| stekern | annoying immu issues: doing a mfspr from immu spr registers while immu is enabled is a royal pain | 06:46 |
| stekern | I need to stall the fetch while doing that since the read will screw up the translation | 06:47 |
| stekern | or do some other magic | 06:48 |
| stekern | or add an read port to the register ram, but that is not very platform independent and might increase resource usage | 06:49 |
| stekern | it's really true that the MMU logic itself is dead simple, it's all the crap around it that causes headaches ;) | 06:51 |
| stekern | maybe I still go for the dpram, at least for starters | 07:00 |
| blueCmd | stekern: sadly it's userspace I want to debug | 12:21 |
| LoneTech | for userspace debug, I guess we'd want to run gdbserver | 12:26 |
| blueCmd | time for some venting. http://pastebin.com/UNu68Ybr | 12:32 |
| blueCmd | compiling with -O causes gcc to remove the use of r2 (frame pointer) which DWARF2 seems to really use | 12:33 |
| blueCmd | -O shouldn't remove stuff that's needed :( | 12:33 |
| blueCmd | I guess I have to add some explicit save for it in the prologue and epilogue | 12:34 |
| blueCmd | I also needed to modify the got instruction to not clobber r9 (it uses a jal). it shouldn't be needed since r9 is stored on the stack which is really the value that DWARF should use. | 12:35 |
| blueCmd | i guess I need to trace where it reads r9 instead of the stack. | 12:36 |
| stekern | -O will remove frame pointer, yes | 13:08 |
| stekern | (in some cases where it's not needed) | 13:08 |
| stekern | debugging purposes not included, but I don't think -O cares about that | 13:09 |
| stekern | blueCmd: ... and what do you mean by "modify got instruction to not clobber r9"? | 13:10 |
| stekern | it clobber it because it needs to clobber it, no? | 13:11 |
| stekern | (to get the pc into r9) | 13:11 |
| blueCmd | stekern: yes, I "solved" it by saving r9 and then restoring it | 13:15 |
| blueCmd | in the got instruction, clobbering r19 or something like that | 13:15 |
| blueCmd | I really want to solve it in some other way | 13:16 |
| stekern | you mean you are doing: save r9; get got; restore r9 | 13:16 |
| blueCmd | yep | 13:17 |
| stekern | and put r19 in the clobberlist for the get_got description? | 13:17 |
| blueCmd | yep | 13:18 |
| stekern | ok, yeah, that sounds like a hack ;) | 13:18 |
| blueCmd | yep :) | 13:18 |
| stekern | ...but there could well be dragons in the stack saving stuff for r9 in functions using the got instruction | 13:18 |
| blueCmd | but it helped me identify some other things, like saving the FP | 13:18 |
| stekern | you might have seen my "HACK" note in there | 13:18 |
| blueCmd | ah, no. I read it now | 13:19 |
| stekern | I never managed to get that properly sorted out | 13:19 |
| stekern | IIRC, the problem is that you don't know if you'll need the got pointer when the initial stack frame calculation is done | 13:20 |
| blueCmd | well, stuff like that might need some sort of CFA update. | 13:20 |
| stekern | what did your pastebin show btw? | 13:31 |
| stekern | I didn't quite get it ;) | 13:31 |
| blueCmd | stekern: ah, 1 sec | 13:40 |
| blueCmd | http://pastebin.com/0WG3X4YZ | 13:40 |
| blueCmd | stekern: it's a program that uses the Unwind_Backtrace thing in libgcc | 13:41 |
| blueCmd | I use it to test that the frame information is saved as it should | 13:41 |
| blueCmd | with -O it outputs a faulty backtrace, without it it works | 13:42 |
| stekern | ah, ok | 13:46 |
| stekern | how does that Unwind_Backtrace work? | 13:47 |
| blueCmd | as I understand it, it calls the function given for each frame in the stack | 13:48 |
| blueCmd | I don't think it works with SJLJ exceptions that or1k uses without my patches | 13:48 |
| blueCmd | I never tried it before switching to DWARF2 though | 13:48 |
| stekern | have you tried that with the old or32 toolchain? | 13:50 |
| blueCmd | nope | 13:50 |
| stekern | but you say it relies on the frame pointer? | 13:54 |
| stekern | http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Optimize-Options.html | 13:54 |
| stekern | "-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. " | 13:54 |
| stekern | does -O turn on -fomit-frame-pointer on or1k-gcc? | 13:55 |
| blueCmd | aha | 13:55 |
| blueCmd | I will check | 13:55 |
| stekern | I mean, if we really need the frame pointer for debugging properly, then we probably should turn that off for -O | 13:56 |
| blueCmd | yeah | 13:56 |
| blueCmd | yepp it does | 13:58 |
| blueCmd | cool | 13:58 |
| blueCmd | -fno-omit-frame-pointer fixes it | 13:58 |
| blueCmd | great! | 13:58 |
| stekern | one problem less, infinite to go! right? ;) | 13:59 |
| blueCmd | haha, n-1 is n-1 nonetheless | 13:59 |
| blueCmd | Now I just need to find where to set that | 13:59 |
| stekern | true, so true | 13:59 |
| stekern | that's the engineers sole motivation ;) | 14:00 |
| blueCmd | hm, frame pointers shouldn't be needed though - DWARF should use the offset directives | 14:04 |
| blueCmd | oh well, it's good for reference atleast | 14:04 |
| blueCmd | I guess that's why tilepro saves the SP to the stack. I'm in the progress of creating something like that for or1k, it will hopefully solve things | 14:06 |
| stekern | excuse my ignorance (again) ;) how does the offset directives work? | 14:14 |
| stekern | I mean, how does it get the offset if it doesn't have the frame pointer? | 14:15 |
| blueCmd | no problem, it's probably just healthy to question these things | 14:17 |
| blueCmd | the offset works by recording offsets relative to the stack pointer | 14:17 |
| blueCmd | instrumenting r1 of sorts. when R1 is updated, the CFI is also updated so it can always go back to get variables that has been pushed to the stack | 14:18 |
| blueCmd | (if I understood it correctly) | 14:18 |
| LoneTech | it probably requires additional assistance if you involve variable automatic arrays or alloca() | 14:18 |
| blueCmd | LoneTech: you are correct, which gave me an idea. | 14:19 |
| blueCmd | TARGET_FRAME_POINTER_REQUIRED | 14:20 |
| blueCmd | return crtl->calls_eh_return || cfun->calls_alloca; | 14:20 |
| blueCmd | on other arch | 14:20 |
| blueCmd | I don't think or1k has that one | 14:20 |
| blueCmd | might be something | 14:20 |
| LoneTech | I did not know about eh_return.. looks like some gcc internal | 14:23 |
| stekern | LoneTech: you will always have the frame pointer on automatic arrays, alloca and dynamic stack relocation | 14:24 |
| blueCmd | yes, it's what DWARF2 unwinding uses to jump to catches I think | 14:24 |
| LoneTech | makes sense | 14:24 |
| blueCmd | it's almost unreal how much I have learned about the inner workings of gcc, assembler, linker, exceptions, backtraces just in the last couple of days. | 14:55 |
| blueCmd | it's great fun | 14:56 |
| stekern | blueCmd: I know the feeling, it's really learning by doing. I got the same feeling when hacking on LLVM and the dynamic linking stuff | 15:02 |
| blueCmd | stekern: indeed | 15:03 |
| stekern | and yes, it's great fun! ;) | 15:03 |
| stekern | unrelated fact: it's a _lot_ easier to make a ethernet hub using RMII than MII | 15:05 |
| blueCmd | as someone who have worked a bit with writing FPGA ethernet stuff, how so? | 15:08 |
| stekern | because you only have to worry about one clock instead of four (out of sync) clocks | 15:08 |
| stekern | if you consider 2 PHYs | 15:09 |
| stekern | well, the tx clocks might be in sync with each other | 15:09 |
| stekern | but the rx clock is not in sync with the tx clock and it's not in sync with the rx clock of the other phy | 15:10 |
| blueCmd | ah, that's nice | 15:12 |
| _franck_ | but your 2 PHY must share the same clock right ? | 15:14 |
| stekern | _franck_: in RMII mode, they have the same 50MHz refclk, yes | 15:15 |
| _franck_ | I could be interrested in such a design one day. We were about to use this in a project, but we went for another option | 15:17 |
| stekern | well, if you do and you have the choice to choose between MII and RMII, you know what to choose ;) | 15:18 |
| _franck_ | yeah sure, I didn't know that and I was thinking of the hard time I would have with 4 clocks :) | 15:19 |
| blueCmd | omg | 18:09 |
| blueCmd | I just got the most satisfying "AHA!" moment | 18:09 |
| blueCmd | and now exceptions seems to be working | 18:09 |
| blueCmd | woo | 18:09 |
| stekern | excellent! ;) | 18:46 |
| blueCmd | 2 things left, signals from kernel and that damn GOT | 18:46 |
| blueCmd | stekern: you don't happen to know if the assembler thinks that all l.jal are function calls? | 18:46 |
| stekern | I don't think the assembler think anything about l.jal | 18:47 |
| blueCmd | i'm thinking if it injects CFIs to update r9 or something | 18:47 |
| stekern | hmm, no, I don't think the assembler does such things. | 19:04 |
| blueCmd | well, it's the assembler that writes the cfi instructions for the dwarf intretor | 19:05 |
| blueCmd | interpretor* | 19:05 |
| stekern | yes, but the cfi directives are already in the .S file, right? | 19:06 |
| stekern | I'm not 100% certain, but it feels like all of those should always be there when the assembler comes into play | 19:07 |
| blueCmd | I'm not sure - I don't know if there are implicit directives | 19:07 |
| blueCmd | it sounds wired though | 19:07 |
| blueCmd | weird* | 19:08 |
| stekern | yeah, that's my point, it doesn't make sense to me that the assembler would need to do some thinking there | 19:08 |
| blueCmd | you're probably right | 19:09 |
| stekern | but, I'm just guessing and going on gut-feel on that ;) | 19:09 |
| blueCmd | gut feeling isn't normally such a bad thing | 19:11 |
| blueCmd | stekern: I think I found something | 19:18 |
| blueCmd | http://pastebin.com/Fqx4WZvM | 19:18 |
| blueCmd | notice "after the prologue" | 19:18 |
| blueCmd | GOT is inside the prologue, so we can't use LINK_REGNUM like that | 19:18 |
| blueCmd | stekern: how verbose do you want the changelog to be? | 22:15 |
| jeremybennett | blueCmd: Are you working on the GNU toolchain - I haven't been following the whole conversation | 22:16 |
| blueCmd | jeremybennett: yes | 22:16 |
| jeremybennett | In that case they should follow the GNU coding standard: http://www.gnu.org/prep/standards/html_node/Change-Logs.html | 22:17 |
| jeremybennett | That way if we ever commit upstream, there won't be a problem. | 22:17 |
| jeremybennett | Assuming you are using the GitHub code base, convention is then to include the ChangeLog entry in your commit message. | 22:17 |
| jeremybennett | That way, those who insist on only having ChangeLogs in commit messages have the identical information. | 22:18 |
| blueCmd | jeremybennett: http://pastebin.com/EEeC9g9M is this too verbose? | 22:22 |
| jeremybennett | That looks fine to me. | 22:23 |
| blueCmd | great | 22:24 |
| jeremybennett | Thanks for the work on this. Look forward to seeing the regression test results after all your work. | 22:24 |
| blueCmd | jeremybennett: hah, me too | 22:25 |
| _franck_ | jeremybennett: I'm going to try the regression suite again | 22:25 |
| blueCmd | jeremybennett: it's my pleasure - this is really exciting work | 22:25 |
| _franck_ | http://www.embecosm.com/appnotes/ean3/html/ch02s09.html | 22:25 |
| _franck_ | you say: "These configuration files can be used to specify a suitable simulator and how to connect it " | 22:26 |
| _franck_ | do we have a file configurer for or1ksim ? | 22:26 |
| jeremybennett | There should be configuration somewhere in the SVN tree. | 22:26 |
| blueCmd | jeremybennett: I'm thinking of setting up regression testing - is there an image or something that I can use? I don't really fancy spending time on building busybocx and everyhing | 22:26 |
| jeremybennett | When you are using a unified tree (as we do for the whole tool chain), you'll want "make check-gdb" etc to run the specific tool tests. | 22:27 |
| blueCmd | _franck_: perhaps we are on the same mission? | 22:27 |
| _franck_ | may be :) | 22:27 |
| jeremybennett | blueCmd: If you are testing the ELF tool chain you don't need Linux etc. | 22:27 |
| jeremybennett | Just taking a look at SVN to see what is lying around. | 22:27 |
| blueCmd | jeremybennett: i want to run the gcc suite | 22:28 |
| blueCmd | and g++ | 22:28 |
| _franck_ | jeremybennett: on a fresh gnustable checkout, make checkgdb gives me hundreds of failed tests | 22:28 |
| jeremybennett | so you'll need "make check-gcc" | 22:28 |
| jeremybennett | and "make check-target-libstdc++-v3" for the library | 22:28 |
| blueCmd | jeremybennett: http://pastebin.com/fjMU7dyX those are the instructions I were given | 22:29 |
| jeremybennett | _franck_: Is that with the ELF or Linux tool chain. | 22:29 |
| * blueCmd sleeps while jeremybennett helps _franck_ :) | 22:29 | |
| _franck_ | ELF | 22:29 |
| jeremybennett | Haha - see stekern fingered me as the one to sort it out. | 22:29 |
| jeremybennett | For ELF it should work pretty cleanly with Or1ksim. | 22:30 |
| jeremybennett | Just make sure you have the DEJAGNU environment variable pointing to site.exp, which will then make sure or32-elf-xxx picks up the right board specification (you'll need to edit or32 to be or1k). | 22:31 |
| jeremybennett | A quick check and gnu-stable has site.exp and boards directory that should get you going. | 22:32 |
| _franck_ | ok, I didn't set the DEJAGNU environment variable, I was thinking the makefile did that | 22:33 |
| jeremybennett | I don't think you need TUN/TAP for elf, it just runs the target as a simulator. | 22:33 |
| jeremybennett | No - you need to set DEJAGNU | 22:33 |
| jeremybennett | On GDB last time I ran it for ELF it got 253 failures (GDB 7.2). | 22:34 |
| _franck_ | yeah looks like it is much better with "export DEJAGNU=....../site.exp" | 22:34 |
| _franck_ | blueCmd: your turn to "use" jeremybennett for help :) | 22:35 |
| jeremybennett | Always glad to be of assistance :) | 22:36 |
| blueCmd | _franck_: ;D | 22:36 |
| _franck_ | I'm almost done with openOCD, now I'm getting back to gdb | 22:36 |
| blueCmd | aw crap. I committed and pushed "2012-01-11" as the date. | 22:36 |
| jeremybennett | You can fix it next time. | 22:36 |
| blueCmd | Oh well | 22:36 |
| jeremybennett | btw _franck_ Thanks for all your work on GDB. The idea of how to use SPRs as registers is one I hadn't come across before, and I'll be using it elsewhere. | 22:38 |
| _franck_ | jeremybennett: nice to here that | 22:39 |
| _franck_ | 256 failures | 22:39 |
| _franck_ | at least it works much better, now I need to make it work with or1k toolchain | 22:40 |
| jeremybennett | That's a good starting point. Look forward to hearing the or1k results | 22:41 |
| _franck_ | jeremybennett: do you know why we have an *or1k*-dejagnu ? | 22:42 |
| jeremybennett | No - where is that? | 22:42 |
| jeremybennett | A long time ago, OpenRISC GDB used or1k, rather than or32. But then it was changed to used or32 for consistency (around 2009). | 22:43 |
| _franck_ | on openrisc github | 22:43 |
| jeremybennett | Ah - probably new stuff someone has been working on. stekern might know. Is there a log of who committed it? | 22:43 |
| _franck_ | or1k: add or1k/or1knd targets, add baseboard for or1k GNU cgen simulator | 22:44 |
| _franck_ | in the log, this is what I would need I guess | 22:44 |
| jeremybennett | That looks like it is one to use the CGEN simulator rather than Or1ksim. Depends which you trust more. | 22:45 |
| jeremybennett | There is always the slight risk with CGEN that you are rather testing against yourself. So using Or1ksim is quite a good thing to do if you can. | 22:45 |
| _franck_ | if I can or "if I know how" :) | 22:45 |
| jeremybennett | The or1ksim stuff should be a simple translation of or32->or1k in the site.exp and boards/* files | 22:49 |
| blueCmd | hah, the patch is laughably small after all cleanup https://github.com/openrisc/or1k-gcc/pull/3/files | 22:53 |
| _franck_ | jeremybennett: if I change "The name of the sim subdir in src/sim" in or32-elf-sim.exp to "setup_sim or1k" I'll use libsim.a generated from the CGEN simu ? | 22:57 |
| * _franck_ doesn't know exactly (for now) what he's doing | 22:58 | |
| blueCmd | stekern: pull requests away! | 22:59 |
| jeremybennett | _franck_: I'm not sure - I think that's right. I haven't looked at this stuff for a long time. | 23:00 |
| blueCmd | jeremybennett: do you know of any userspace image I can use to run the test suite? | 23:00 |
| _franck_ | jeremybennett: ok, I'll figure out something ;) | 23:00 |
| jeremybennett | blueCmd: Not sure I understand the question. | 23:00 |
| blueCmd | as I understand it: | 23:01 |
| blueCmd | or1k-linux-sim.exp telnets in into the environment that runs under or1ksim | 23:01 |
| blueCmd | then it FTPs the files to run and runs them | 23:01 |
| jeremybennett | For ELF, the simulator essentially runs <simulator_cmd> <arguments from test suite> and the discussion with _franck_ was about how the board scripts identify what <simulator_cmd> is. | 23:01 |
| blueCmd | well, this is or1k-linux | 23:02 |
| jeremybennett | blueCmd: OK - for Linux its different. | 23:02 |
| blueCmd | yes | 23:02 |
| jeremybennett | It just needs an IP address of a Linux system and it uses telnet and FTP to copy compiled tests across and run them. | 23:02 |
| jeremybennett | So what you need is a running OpenRISC Linux system. | 23:03 |
| jeremybennett | But to do that in Simulation, you need Or1ksim running with a TUN/TAP virtual IP address, which requires capabilities that usually only superusers have. | 23:03 |
| blueCmd | yes, and I'm too lazy to build one from scratch | 23:03 |
| jeremybennett | You also will need superuser to set up the TUN/TAP. | 23:03 |
| blueCmd | jeremybennett: that's no problem | 23:04 |
| jeremybennett | But if you ask I expect someone here has a vmlinux image that you could FTP - not me I'm afraid. | 23:04 |
| jeremybennett | Just make sure you have the FTP and TELNET services running. | 23:04 |
| blueCmd | jeremybennett: ah, yes - I have the kernel itself. I just want to get around compiling the userspace things | 23:06 |
| blueCmd | jeremybennett: i will continue poking stekern then :) | 23:06 |
| jeremybennett | OK - good luck. I gotta go soon. | 23:23 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!