| --- Log opened Wed Apr 30 00:00:27 2014 | ||
| stekern | blueCmd: the binutils git access got sorted out now | 03:43 |
|---|---|---|
| stekern | ah, my parallella just got shipped | 06:29 |
| ams | stekern: bastard | 07:42 |
| stekern | ams: you're probably right, but for what reason now? ;) | 07:44 |
| ams | stekern: parallella | 07:44 |
| stekern | I see, are you waiting for one too? | 07:44 |
| ams | no, but i want one | 07:44 |
| ams | i'm only alllowed to play with stuff like https://www.pjrc.com/teensy/ | 07:45 |
| stekern | heh, allowed? do you have a court issued restraining order against heavier stuff? | 07:46 |
| stekern | don't get closer than 50 feet to anything with > 8 bits ;) | 07:47 |
| ams | yes, time court | 07:47 |
| stekern | oh, that old party pooper, now it too well | 07:51 |
| stekern | s/now/know | 07:51 |
| blueCmd | bah, my fake_atomics.o made it into the exports of pulseaudio so now you cannot link anything to it :P | 08:10 |
| blueCmd | at least poke53281 and stekern's patch seems to work | 08:41 |
| stekern | great | 09:02 |
| stekern | oh, how I love encrypted vhdl files... | 09:28 |
| blueCmd | ROT13 encrypted I hope? | 09:36 |
| stekern | I've complemented this a bit http://opencores.org/or1k/OR1K:DevelopmentOverview | 09:38 |
| blueCmd | stekern: I'm gonna write us on gcc maintainers as well | 09:45 |
| blueCmd | like it or not, that's how it is basically :P | 09:45 |
| stekern | yeah, that's fine | 09:45 |
| stekern | newlib and uClibc, dunno | 09:46 |
| stekern | I've been throwing patches at uClibc, but I wouldn't call it maintaining | 09:46 |
| stekern | empty maintainer entries are of course fine too | 09:47 |
| stekern | but it would be good to have scape goats ;) | 09:48 |
| blueCmd | hah | 09:51 |
| blueCmd | yes | 09:51 |
| blueCmd | http://myriadrf.org/sdr-enabling-the-novena-open-hardware-laptop/ | 09:53 |
| blueCmd | Maybe we should deprecated Bugzilla | 09:57 |
| blueCmd | and use github's "issues" | 09:57 |
| stekern | bah, it's not open hardware unless you engrave the transistors into the silicon with rocks you've picked on chilly spring morning | 10:00 |
| stekern | +a | 10:00 |
| blueCmd | exactly! | 10:05 |
| blueCmd | stekern: so, rebuilding glibc makes it work for -static, but not otherwise | 10:26 |
| blueCmd | I'm thinking that maybe ld.so's fini is misnamed still, hmm | 10:26 |
| wallento | stekern: thanks for table updates | 10:31 |
| blueCmd | I'm gonna rebuild it again with the fixed one | 10:33 |
| stekern | wallento: np, I see that _franck__ and blueCmd have helped out a bit too | 10:49 |
| wallento | thanks too then | 10:49 |
| wallento | after discussing my recent change proposals to newlib, I would be ready to maintain | 10:49 |
| wallento | how about jeremybennett and juliusb? | 10:50 |
| stekern | yes, I think they are the ones that have been most active in the newlib department previously | 10:51 |
| stekern | but I don't know how eager they are to maintain their maintainance roles at the moment | 11:00 |
| blueCmd | generally I don't think people will fight you over maintainer roles.. | 11:02 |
| wallento | neither do I ;) | 11:08 |
| wallento | I will try to reconstruct the various OSs state | 11:13 |
| blueCmd | wallento: 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 |
| stekern | I think wallento have shown he's very persistant in the past ;) | 11:33 |
| stekern | I mean, apart from jeremybennett, I think he is the longest lasting OpenRISCer of us all | 11:35 |
| wallento | yeah, persistent but not continuous :) | 11:36 |
| blueCmd | stekern: LD_DEBUG=all doesn't print 'calling fini: ./a.out [0]' as it should, so I'm onto something! | 12:35 |
| blueCmd | more on that this evening | 12:35 |
| * stekern is waiting with "vappusima ja munkit" for the great show | 13:00 | |
| stekern | _franck__: I'm continuing debugging Jose had with next, I can reproduce it on the de0_nano board now | 14:11 |
| stekern | *debugging the problem | 14:11 |
| stekern | this is my test program: http://pastie.org/9127869 | 14:13 |
| _franck__ | is on both or1200 and mor1kx ? | 14:13 |
| _franck__ | *it | 14:13 |
| stekern | so far only on mor1kx | 14:16 |
| stekern | I'm building a or1200 image now too | 14:16 |
| _franck__ | don't you test it in simulation ? | 14:16 |
| stekern | now if I set a breakpoint at 20 and 21 (21 for next step) and start nexting: http://pastie.org/9127877 | 14:17 |
| stekern | it breaks at the first function at 20 and steps 'over' it | 14:18 |
| stekern | no, I can't get it to work at all with mor1kx in simulation | 14:18 |
| stekern | the rsp server doesn't start | 14:18 |
| _franck__ | strange, I'll try to fix that tonight | 14:19 |
| stekern | but bare with me, I'll arrive at a question | 14:19 |
| stekern | ah, well, this is in Joses old repo | 14:19 |
| stekern | now, if I just run the program between those two breakpoints, everything works fine, it breaks at line 20 and 21 | 14:21 |
| stekern | shouldn't 'next' essentially just be gdb doing the same, but automatically? | 14:21 |
| stekern | well, there should of course be breakpoints at every line in main() | 14:22 |
| stekern | I'll try that and see if I can get the same behaviour | 14:22 |
| stekern | if not, how does that "automatically detect stack frame" work? | 14:23 |
| stekern | does it need to access registers (r9) (as I explained yesterday... not supported yet) | 14:23 |
| stekern | man, 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 again | 14:24 |
| _franck__ | :) | 14:24 |
| stekern | line 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 programs | 14:25 |
| _franck__ | we should add jtag_vpi support in both or1200-generic and mor1kx-generic systems | 14:27 |
| stekern | ok, setting breakpoints on each line in main() works too | 14:27 |
| stekern | so it has to be the "detect where to insert the breakpoint" that fails somehow | 14:28 |
| stekern | because, 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" works | 14:33 |
| stekern | and yes, we should get jtag_vpi work in mor1kx/or1200-generic | 14:34 |
| stekern | especially with verilator | 14:34 |
| stekern | to work | 14:34 |
| stekern | jeremybennett_: could you give some insight on this? | 14:34 |
| _franck__ | (jtag_vpi) I'll do that | 14:34 |
| stekern | yeah, can't say it really works with or1200 neither, it's just broken in a different way | 14:37 |
| stekern | if I set a break point at 20 and then 'next' after that | 14:38 |
| stekern | it steps over line 20: f1() | 14:38 |
| stekern | then if I do 'next' again, it steps over 21: f2() | 14:39 |
| stekern | but then it get 'stuck' on line 22: } | 14:39 |
| stekern | and continously doing 'next' will just end up on that line | 14:40 |
| stekern | or is it actually single-stepping to a certain address when you do next? | 14:45 |
| stekern | but single-stepping manually through the whole program works, so it still has to be related to the 'detection' somehow | 14:47 |
| _franck__ | next is supposed to act like step but when a function call arrives, it doesn't jump into it | 14:47 |
| _franck__ | it is supposed to step just after this function | 14:48 |
| stekern | right | 14: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 |
| stekern | yes, there's a debug line section. the program is compiled with -O0 -g. | 15:16 |
| stekern | I think there are hardware problems, but I'd like to know how 'next' works (at least high level picture) to be able to pinpoint them | 15:17 |
| stekern | but debug output might be helpful | 15:18 |
| stekern | to see what actually happens | 15:18 |
| stekern | si stepping through the whole program with mor1kx actually shows some problems too... | 15:20 |
| stekern | http://pastie.org/9128081 for reference, thats a session with set debug remote 1 | 15:28 |
| stekern | ok, Z0 is software breakpoint, that should at least give us the info at what addresses it thinks the next line is | 15:31 |
| stekern | ah, no... that's just the breakpoint at line 20 | 15:34 |
| stekern | so... how can I know what the package mean? | 15:34 |
| stekern | oh, I found this nice appnote from www.embecosm.com :) | 15:40 |
| stekern | hmm, I think I've found, if not *the* problem, *a* problem with mor1kx | 15:52 |
| stekern | it (sometimes) goes into the trap exception when single stepping over a software breakpoint | 15:53 |
| Findeton | hey | 19:36 |
| Findeton | whats up | 19:36 |
| _franck_ | stekern: a quick test with or1200-generic shows me that next work: http://pastie.org/private/7t0ogb0cs4usdhn2lmib8w | 20:41 |
| _franck_ | am I doing the good test ? | 20:41 |
| _franck_ | you'll find the patch for or1200-generic here: https://github.com/fjullien/orpsoc-cores/commit/14c451ab3ccf0ea54ce7ea9870d6065b56272a19 | 20:46 |
| _franck_ | making jtag_vpi work with the verilator cpp testbench won't be trivial... | 21:19 |
| blueCmd | hm, weird - the output has two _fini symbols | 23:09 |
| blueCmd | http://49ec3bebdfe5dd91.paste.se/ | 23:09 |
| --- Log closed Thu May 01 00:00:29 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!