IRC logs for #openrisc Tuesday, 2013-01-22

_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 yet00:05
blueCmd_franck_: yeah00:05
_franck_if you want to work on it I have some information. Jonas Bonn start something00:07
_franck_before I continue working on gdb I'd like to run this f*!?ing testsuite00: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 frames00:22
blueCmdI don't think I need gdbserver for that - not sure.00:22
blueCmdqemu has some interface to talk to gdb if I'm not misstaken00: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.c00:24
blueCmd_franck_: fair enough00: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 working00:27
_franck_or sometimes I use barebox as a test program which is not linked to newlib00:28
_franck_barebox is like uboot00:28
blueCmd_franck_: aha! cool00:43
blueCmdI didn't even know you could do that - nice!00:43
stekernblueCmd: if you want to debug the kernel (i.e. not user space) you should be able to use the elf-gdb06:45
stekernannoying immu issues: doing a mfspr from immu spr registers while immu is enabled is a royal pain06:46
stekernI need to stall the fetch while doing that since the read will screw up the translation06:47
stekernor do some other magic06:48
stekernor add an read port to the register ram, but that is not very platform independent and might increase resource usage06:49
stekernit's really true that the MMU logic itself is dead simple, it's all the crap around it that causes headaches ;)06:51
stekernmaybe I still go for the dpram, at least for starters07:00
blueCmdstekern: sadly it's userspace I want to debug12:21
LoneTechfor userspace debug, I guess we'd want to run gdbserver12:26
blueCmdtime for some venting.
blueCmdcompiling with -O causes gcc to remove the use of r2 (frame pointer) which DWARF2 seems to really use12:33
blueCmd-O shouldn't remove stuff that's needed :(12:33
blueCmdI guess I have to add some explicit save for it in the prologue and epilogue12:34
blueCmdI 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
blueCmdi guess I need to trace where it reads r9 instead of the stack.12:36
stekern-O will remove frame pointer, yes13:08
stekern(in some cases where it's not needed)13:08
stekerndebugging purposes not included, but I don't think -O cares about that13:09
stekernblueCmd: ... and what do you mean by "modify got instruction to not clobber r9"?13:10
stekernit clobber it because it needs to clobber it, no?13:11
stekern(to get the pc into r9)13:11
blueCmdstekern: yes, I "solved" it by saving r9 and then restoring it13:15
blueCmdin the got instruction, clobbering r19 or something like that13:15
blueCmdI really want to solve it in some other way13:16
stekernyou mean you are doing: save r9; get got; restore r913:16
stekernand put r19 in the clobberlist for the get_got description?13:17
stekernok, yeah, that sounds like a hack ;)13:18
blueCmdyep :)13:18
stekern...but there could well be dragons in the stack saving stuff for r9 in functions using the got instruction13:18
blueCmdbut it helped me identify some other things, like saving the FP13:18
stekernyou might have seen my "HACK" note in there13:18
blueCmdah, no. I read it now13:19
stekernI never managed to get that properly sorted out13:19
stekernIIRC, the problem is that you don't know if you'll need the got pointer when the initial stack frame calculation is done13:20
blueCmdwell, stuff like that might need some sort of CFA update.13:20
stekernwhat did your pastebin show btw?13:31
stekernI didn't quite get it ;)13:31
blueCmdstekern: ah, 1 sec13:40
blueCmdstekern: it's a program that uses the Unwind_Backtrace thing in libgcc13:41
blueCmdI use it to test that the frame information is saved as it should13:41
blueCmdwith -O it outputs a faulty backtrace, without it it works13:42
stekernah, ok13:46
stekernhow does that Unwind_Backtrace work?13:47
blueCmdas I understand it, it calls the function given for each frame in the stack13:48
blueCmdI don't think it works with SJLJ exceptions that or1k uses without my patches13:48
blueCmdI never tried it before switching to DWARF2 though13:48
stekernhave you tried that with the old or32 toolchain?13:50
stekernbut you say it relies on the frame pointer?13:54
stekern"-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. "13:54
stekerndoes -O turn on -fomit-frame-pointer on or1k-gcc?13:55
blueCmdI will check13:55
stekernI mean, if we really need the frame pointer for debugging properly, then we probably should turn that off for -O13:56
blueCmdyepp it does13:58
blueCmd-fno-omit-frame-pointer fixes it13:58
stekernone problem less, infinite to go! right? ;)13:59
blueCmdhaha, n-1 is n-1 nonetheless13:59
blueCmdNow I just need to find where to set that13:59
stekerntrue, so true13:59
stekernthat's the engineers sole motivation ;)14:00
blueCmdhm, frame pointers shouldn't be needed though - DWARF should use the offset directives14:04
blueCmdoh well, it's good for reference atleast14:04
blueCmdI 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 things14:06
stekernexcuse my ignorance (again) ;) how does the offset directives work?14:14
stekernI mean, how does it get the offset if it doesn't have the frame pointer?14:15
blueCmdno problem, it's probably just healthy to question these things14:17
blueCmdthe offset works by recording offsets relative to the stack pointer14:17
blueCmdinstrumenting 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 stack14:18
blueCmd(if I understood it correctly)14:18
LoneTechit probably requires additional assistance if you involve variable automatic arrays or alloca()14:18
blueCmdLoneTech: you are correct, which gave me an idea.14:19
blueCmdreturn crtl->calls_eh_return || cfun->calls_alloca;14:20
blueCmdon other arch14:20
blueCmdI don't think or1k has that one14:20
blueCmdmight be something14:20
LoneTechI did not know about eh_return.. looks like some gcc internal14:23
stekernLoneTech: you will always have the frame pointer on automatic arrays, alloca and dynamic stack relocation14:24
blueCmdyes, it's what DWARF2 unwinding uses to jump to catches I think14:24
LoneTechmakes sense14:24
blueCmdit'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
blueCmdit's great fun14:56
stekernblueCmd: I know the feeling, it's really learning by doing. I got the same feeling when hacking on LLVM and the dynamic linking stuff15:02
blueCmdstekern: indeed15:03
stekernand yes, it's great fun! ;)15:03
stekernunrelated fact: it's a _lot_ easier to make a ethernet hub using RMII than MII15:05
blueCmdas someone who have worked a bit with writing FPGA ethernet stuff, how so?15:08
stekernbecause you only have to worry about one clock instead of four (out of sync) clocks15:08
stekernif you consider 2 PHYs15:09
stekernwell, the tx clocks might be in sync with each other15:09
stekernbut the rx clock is not in sync with the tx clock and it's not in sync with the rx clock of the other phy15:10
blueCmdah, that's nice15: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, yes15: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 option15:17
stekernwell, 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
blueCmdI just got the most satisfying "AHA!" moment18:09
blueCmdand now exceptions seems to be working18:09
stekernexcellent! ;)18:46
blueCmd2 things left, signals from kernel and that damn GOT18:46
blueCmdstekern: you don't happen to know if the assembler thinks that all l.jal are function calls?18:46
stekernI don't think the assembler think anything about l.jal18:47
blueCmdi'm thinking if it injects CFIs to update r9 or something18:47
stekernhmm, no, I don't think the assembler does such things.19:04
blueCmdwell, it's the assembler that writes the cfi instructions for the dwarf intretor19:05
stekernyes, but the cfi directives are already in the .S file, right?19:06
stekernI'm not 100% certain, but it feels like all of those should always be there when the assembler comes into play19:07
blueCmdI'm not sure - I don't know if there are implicit directives19:07
blueCmdit sounds wired though19:07
stekernyeah, that's my point, it doesn't make sense to me that the assembler would need to do some thinking there19:08
blueCmdyou're probably right19:09
stekernbut, I'm just guessing and going on gut-feel on that ;)19:09
blueCmdgut feeling isn't normally such a bad thing19:11
blueCmdstekern: I think I found something19:18
blueCmdnotice "after the prologue"19:18
blueCmdGOT is inside the prologue, so we can't use LINK_REGNUM like that19:18
blueCmdstekern: how verbose do you want the changelog to be?22:15
jeremybennettblueCmd: Are you working on the GNU toolchain - I haven't been following the whole conversation22:16
blueCmdjeremybennett: yes22:16
jeremybennettIn that case they should follow the GNU coding standard:
jeremybennettThat way if we ever commit upstream, there won't be a problem.22:17
jeremybennettAssuming you are using the GitHub code base, convention is then to include the ChangeLog entry in your commit message.22:17
jeremybennettThat way, those who insist on only having ChangeLogs in commit messages have the identical information.22:18
blueCmdjeremybennett: is this too verbose?22:22
jeremybennettThat looks fine to me.22:23
jeremybennettThanks for the work on this. Look forward to seeing the regression test results after all your work.22:24
blueCmdjeremybennett: hah, me too22:25
_franck_jeremybennett: I'm going to try the regression suite again22:25
blueCmdjeremybennett: it's my pleasure - this is really exciting work22: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
jeremybennettThere should be configuration somewhere in the SVN tree.22:26
blueCmdjeremybennett: 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 everyhing22:26
jeremybennettWhen 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
jeremybennettblueCmd: If you are testing the ELF tool chain you don't need Linux etc.22:27
jeremybennettJust taking a look at SVN to see what is lying around.22:27
blueCmdjeremybennett: i want to run the gcc suite22:28
blueCmdand g++22:28
_franck_jeremybennett: on a fresh gnustable checkout, make checkgdb gives me hundreds of failed tests22:28
jeremybennettso you'll need "make check-gcc"22:28
jeremybennettand "make check-target-libstdc++-v3" for the library22:28
blueCmdjeremybennett: those are the instructions I were given22:29
jeremybennett_franck_: Is that with the ELF or Linux tool chain.22:29
* blueCmd sleeps while jeremybennett helps _franck_ :)22:29
jeremybennettHaha - see stekern fingered me as the one to sort it out.22:29
jeremybennettFor ELF it should work pretty cleanly with Or1ksim.22:30
jeremybennettJust 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
jeremybennettA 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 that22:33
jeremybennettI don't think you need TUN/TAP for elf, it just runs the target as a simulator.22:33
jeremybennettNo - you need to set DEJAGNU22:33
jeremybennettOn 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
jeremybennettAlways glad to be of assistance :)22:36
blueCmd_franck_: ;D22:36
_franck_I'm almost done with openOCD, now I'm getting back to gdb22:36
blueCmdaw crap. I committed and pushed "2012-01-11" as the date.22:36
jeremybennettYou can fix it next time.22:36
blueCmdOh well22:36
jeremybennettbtw _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 that22:39
_franck_256 failures22:39
_franck_at least it works much better, now I need to make it work with or1k toolchain22:40
jeremybennettThat's a good starting point. Look forward to hearing the or1k results22:41
_franck_jeremybennett: do you know why we have an *or1k*-dejagnu ?22:42
jeremybennettNo - where is that?22:42
jeremybennettA 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 github22:43
jeremybennettAh - 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 simulator22:44
_franck_in the log, this is what I would need I guess22:44
jeremybennettThat looks like it is one to use the CGEN simulator rather than Or1ksim. Depends which you trust more.22:45
jeremybennettThere 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
jeremybennettThe or1ksim stuff should be a simple translation of or32->or1k in the site.exp and boards/* files22:49
blueCmdhah, the patch is laughably small after all cleanup
_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 doing22:58
blueCmdstekern: 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
blueCmdjeremybennett: 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
jeremybennettblueCmd: Not sure I understand the question.23:00
blueCmdas I understand it:23:01
blueCmdor1k-linux-sim.exp telnets in into the environment that runs under or1ksim23:01
blueCmdthen it FTPs the files to run and runs them23:01
jeremybennettFor 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
blueCmdwell, this is or1k-linux23:02
jeremybennettblueCmd: OK - for Linux its different.23:02
jeremybennettIt 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
jeremybennettSo what you need is a running OpenRISC Linux system.23:03
jeremybennettBut 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
blueCmdyes, and I'm too lazy to build one from scratch23:03
jeremybennettYou also will need superuser to set up the TUN/TAP.23:03
blueCmdjeremybennett: that's no problem23:04
jeremybennettBut if you ask I expect someone here has a vmlinux image that you could FTP - not me I'm afraid.23:04
jeremybennettJust make sure you have the FTP and TELNET services running.23:04
blueCmdjeremybennett: ah, yes - I have the kernel itself. I just want to get around compiling the userspace things23:06
blueCmdjeremybennett: i will continue poking stekern then :)23:06
jeremybennettOK - good luck. I gotta go soon.23:23

Generated by 2.15.2 by Marius Gedminas - find it at!