| --- Log opened Mon Jun 09 00:00:26 2014 | ||
| olofk | Excellent. Looks like everyone has been nice and quiet. I was worried about having to spend the rest of the day looking at back logs. | 11:12 |
|---|---|---|
| stekern | olofk: yes, we were afraid to upset you, so we've kept quiet | 11:32 |
| olofk | stekern: Just what I hoped to hear :) | 11:46 |
| _franck__ | git branhc | 12:03 |
| _franck__ | sorry | 12:04 |
| _franck__ | olofk: do you want me to close pull request #41 on fusesoc ? | 13:46 |
| _franck__ | I was about to clean my branches and found it | 13:47 |
| stekern | http://www.4004.com/ | 14:54 |
| ysionneau | where are the verilog files ? :) | 15:00 |
| jtdesousa | I have managed openocd to output wht looks like profile info | 16:48 |
| jtdesousa | gmon.out | 16:48 |
| jtdesousa | however, if I compile the elf with the -pg option | 16:51 |
| jtdesousa | and run it on the board | 16:51 |
| jtdesousa | while getting the profile info using openocd | 16:51 |
| jtdesousa | then when I try to open the file with or1k-elf-gprof elffile gmon.out | 16:52 |
| jtdesousa | it says gmon.out has unsuppoterted format | 16:52 |
| jtdesousa | it says gmon.out has unsupported format | 16:52 |
| jtdesousa | if I compile the same program on the PC | 16:54 |
| jtdesousa | and run it it produces a good gmon.out file | 16:54 |
| jtdesousa | what is interesting is that gprof and or1k-elf-gprof seem to be the same | 16:55 |
| jtdesousa | if I do something stupid like gprof program_compiled_on_PC gmon.out_produced by openOCD then it does not crash but of course does not dsiplay the statistics | 16:57 |
| jtdesousa | does this make sense to anybody ? | 16:57 |
| olofk | _franck_: I like the functionality of the patch, but there are several issues with the exception handling. I planned to write a response to that, but forgot about it | 17:36 |
| olofk | stekern: Thanks for the de0_fixes review. I've replied to your comments | 18:34 |
| stekern | yup, I saw your coc | 18:41 |
| olofk | :) | 19:10 |
| stekern | this is driving me crazy, I can reliably crash dual-core on de0 nano, but however hard I try, I can't reproduce in verilator | 19:26 |
| stekern | I'm fairly certain that it's still related to the atomic instructions and snooping, and I've created an isolated testcase that use the spinlocks from the kernel and really hammer them | 19:29 |
| stekern | but I can't reproduce the behaviour I see in the kernel on the board | 19:30 |
| stekern | the only thing that might differ is memory latencies, so I've added that to the ram_wb model... | 19:31 |
| stekern | ...that makes the verilator simulation fabously slow | 19:31 |
| stekern | I'm on a +8 hour run now and it's still going strong... | 19:32 |
| stekern | crash, dammit, crash! | 19:32 |
| _franck_ | when this one is accepted http://openocd.zylin.com/#/c/2164/ , we'll finally have a progress bar while loading a file with openocd | 19:58 |
| _franck_ | and we won't have this "does it work ??" moment anymore :) | 19:58 |
| _franck_ | anyone can confirm upstream openocd is still working after that: http://openocd.zylin.com/#/c/1663/ ? | 20:45 |
| jtdesousa | and I am going crazy trying to read the gmon.out produced by openocd into gprof | 20:46 |
| _franck_ | openocd still works :) | 20:55 |
| _franck_ | jtdesousa: you had to fix openocd to make "profile" work on openrisc right ? a segfault somewhere IIRC | 20:57 |
| jtdesousa | that is fixed | 20:58 |
| jtdesousa | now it already produces the file | 20:58 |
| _franck_ | I would says gmon.out from openocd is wrong and you should check its format at hex level | 20:58 |
| jtdesousa | that's what I am doing with emacs | 20:58 |
| _franck_ | good luck :) | 20:58 |
| jtdesousa | thanks :-) | 20:59 |
| jtdesousa | thanks for the tip of it may be wrong | 20:59 |
| _franck_ | and then feel free to push your patch to openocd | 20:59 |
| jtdesousa | OK | 21:00 |
| jtdesousa | on github? | 21:00 |
| _franck_ | you can also ask help here: #openocd or on the mailing list | 21:01 |
| _franck_ | to know if someone has ever tested this feature | 21:01 |
| jtdesousa | Ok I'll try that | 21:01 |
| _franck_ | stekern: do you know what's the differences between jonas tree and the vanilla one ? I mean at arch/ level. Why my busybox works with our tree and not with the vanilla one ? | 21:04 |
| stekern | _franck_: hmm... in his master branch, I think the only thing is the additional syscalls that are missing in the old uclibc we have | 21:09 |
| _franck_ | ok thanks, I'll try to add that | 21:10 |
| stekern | we should just sync our uclibc and he can get rid of those... | 21:11 |
| stekern | or you could try the musl port ;) | 21:12 |
| _franck_ | sure, if you tell me how to build my toolchain | 21:13 |
| stekern | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/include/uapi/asm/unistd.h#n21 | 21:13 |
| stekern | those are the ones that differ | 21:13 |
| _franck_ | thanks | 21:14 |
| stekern | blueCmd: btw, with what kernel headers are you compiling glibc? | 22:00 |
| stekern | not the ones from this I hope? https://github.com/bluecmd/or1k-linux | 22:02 |
| stekern | _franck_: if you want to test, I synced uclibc and pushed it: https://github.com/openrisc/uClibc-or1k | 22:44 |
| --- Log closed Tue Jun 10 00:00:27 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!