IRC logs for #openrisc Wednesday, 2014-04-30

--- Log opened Wed Apr 30 00:00:27 2014
stekernblueCmd: the binutils git access got sorted out now03:43
stekernah, my parallella just got shipped06:29
amsstekern: bastard07:42
stekernams: you're probably right, but for what reason now? ;)07:44
amsstekern: parallella07:44
stekernI see, are you waiting for one too?07:44
amsno, but i want one07:44
amsi'm only alllowed to play with stuff like
stekernheh, allowed? do you have a court issued restraining order against heavier stuff?07:46
stekerndon't get closer than 50 feet to anything with > 8 bits ;)07:47
amsyes, time court07:47
stekernoh, that old party pooper, now it too well07:51
blueCmdbah, my fake_atomics.o made it into the exports of pulseaudio so now you cannot link anything to it :P08:10
blueCmdat least poke53281 and stekern's patch seems to work08:41
stekernoh, how I love encrypted vhdl files...09:28
blueCmdROT13 encrypted I hope?09:36
stekernI've complemented this a bit
blueCmdstekern: I'm gonna write us on gcc maintainers as well09:45
blueCmdlike it or not, that's how it is basically :P09:45
stekernyeah, that's fine09:45
stekernnewlib and uClibc, dunno09:46
stekernI've been throwing patches at uClibc, but I wouldn't call it maintaining09:46
stekernempty maintainer entries are of course fine too09:47
stekernbut it would be good to have scape goats ;)09:48
blueCmdMaybe we should deprecated Bugzilla09:57
blueCmdand use github's "issues"09:57
stekernbah, it's not open hardware unless you engrave the transistors into the silicon with rocks you've picked on chilly spring morning10:00
blueCmdstekern: so, rebuilding glibc makes it work for -static, but not otherwise10:26
blueCmdI'm thinking that maybe's fini is misnamed still, hmm10:26
wallentostekern: thanks for table updates10:31
blueCmdI'm gonna rebuild it again with the fixed one10:33
stekernwallento: np, I see that _franck__ and blueCmd have helped out a bit too10:49
wallentothanks too then10:49
wallentoafter discussing my recent change proposals to newlib, I would be ready to maintain10:49
wallentohow about jeremybennett and juliusb?10:50
stekernyes, I think they are the ones that have been most active in the newlib department previously10:51
stekernbut I don't know how eager they are to maintain their maintainance roles at the moment11:00
blueCmdgenerally I don't think people will fight you over maintainer roles..11:02
wallentoneither do I ;)11:08
wallentoI will try to reconstruct the various OSs state11:13
blueCmdwallento: if you feel like there is something you want to do/have done with the multicore stuff but don't have time to do yourself, don't hesitate to ask people for help - I know I'm very excited about your work and would hate to see it fail (people get bored/stuck/whatever)11:17
stekernI think wallento have shown he's very persistant in the past ;)11:33
stekernI mean, apart from jeremybennett, I think he is the longest lasting OpenRISCer of us all11:35
wallentoyeah, persistent but not continuous :)11:36
blueCmdstekern: LD_DEBUG=all doesn't print 'calling fini: ./a.out [0]' as it should, so I'm onto something!12:35
blueCmdmore on that this evening12:35
* stekern is waiting with "vappusima ja munkit" for the great show13:00
stekern_franck__: I'm continuing debugging Jose had with next, I can reproduce it on the de0_nano board now14:11
stekern*debugging the problem14:11
stekernthis is my test program:
_franck__is on both or1200 and mor1kx ?14:13
stekernso far only on mor1kx14:16
stekernI'm building a or1200 image now too14:16
_franck__don't you test it in simulation ?14:16
stekernnow if I set a breakpoint at 20 and 21 (21 for next step) and start nexting:
stekernit breaks at the first function at 20 and steps 'over' it14:18
stekernno, I can't get it to work at all with mor1kx in simulation14:18
stekernthe rsp server doesn't start14:18
_franck__strange, I'll try to fix that tonight14:19
stekernbut bare with me, I'll arrive at a question14:19
stekernah, well, this is in Joses old repo14:19
stekernnow, if I just run the program between those two breakpoints, everything works fine, it breaks at line 20 and 2114:21
stekernshouldn't 'next' essentially just be gdb doing the same, but automatically?14:21
stekernwell, there should of course be breakpoints at every line in main()14:22
stekernI'll try that and see if I can get the same behaviour14:22
stekernif not, how does that "automatically detect stack frame" work?14:23
stekerndoes it need to access registers (r9) (as I explained yesterday... not supported yet)14:23
stekernman, I don't think I've ever used gdb on this highlevel with openrisc before ;)14:24
_franck__it's too far for me, need to jump into the source code again14:24
stekernline numbers in c source and all ;)14:24
stekern...which might explain why things aren't exactly working like they should...14:25
_franck__I think I've always debug asm tests programs14:25
_franck__we should add jtag_vpi support in both or1200-generic and mor1kx-generic systems14:27
stekernok, setting breakpoints on each line in main() works too14:27
stekernso it has to be the "detect where to insert the breakpoint" that fails somehow14:28
stekernbecause, I assume that's how it works?14:28
_franck__I don't know how "where to insert a breakpoint in asm from C source line" works14:33
stekernand yes, we should get jtag_vpi work in mor1kx/or1200-generic14:34
stekernespecially with verilator14:34
stekernto work14:34
stekernjeremybennett_: could you give some insight on this?14:34
_franck__(jtag_vpi) I'll do that14:34
stekernyeah, can't say it really works with or1200 neither, it's just broken in a different way14:37
stekernif I set a break point at 20 and then 'next' after that14:38
stekernit steps over line 20: f1()14:38
stekernthen if I do 'next' again, it steps over 21: f2()14:39
stekernbut then it get 'stuck' on line 22: }14:39
stekernand continously doing 'next' will just end up on that line14:40
stekernor is it actually single-stepping to a certain address when you do next?14:45
stekernbut single-stepping manually through the whole program works, so it still has to be related to the 'detection' somehow14:47
_franck__next is supposed to act like step but when a function call arrives, it doesn't jump into it14:47
_franck__it is supposed to step just after this function14:48
jeremybennett_stekern: At a first guess it's not got the correct line information. Is there .debug.line section?15:07
jeremybennett_GDB should use that info to work out it has advanced to the next line.15:07
jeremybennett_There can be a catch if functions have been inlined, so you can't tell if you are in caller or callee. But I don't think that is the problem here.15:08
jeremybennett_But thinking further that can't be the problem, because you were able to set a breakpoint on a specific line.15:09
jeremybennett_Do you have a log of a session showing the problem?15:09
jeremybennett_Possibly using set debug remote 1 to show the RSP packets going across.15:09
stekernyes, there's a debug line section. the program is compiled with -O0 -g.15:16
stekernI think there are hardware problems, but I'd like to know how 'next' works (at least high level picture) to be able to pinpoint them15:17
stekernbut debug output might be helpful15:18
stekernto see what actually happens15:18
stekernsi stepping through the whole program with mor1kx actually shows some problems too...15:20
stekern for reference, thats a session with set debug remote 115:28
stekernok, Z0 is software breakpoint, that should at least give us the info at what addresses it thinks the next line is15:31
stekernah, no... that's just the breakpoint at line 2015:34
stekernso... how can I know what the package mean?15:34
stekernoh, I found this nice appnote from :)15:40
stekernhmm, I think I've found, if not *the* problem, *a* problem with mor1kx15:52
stekernit (sometimes) goes into the trap exception when single stepping over a software breakpoint15:53
Findetonwhats up19:36
_franck_stekern: a quick test with or1200-generic shows me that next work:
_franck_am I doing the good test ?20:41
_franck_you'll find the patch for or1200-generic here:
_franck_making jtag_vpi work with the verilator cpp testbench won't be trivial...21:19
blueCmdhm, weird - the output has two _fini symbols23:09
--- Log closed Thu May 01 00:00:29 2014

Generated by 2.15.2 by Marius Gedminas - find it at!