| @stekern | nice job _franck_! | 05:35 |
|---|---|---|
| @stekern | do I understand your e-mail correct, that single stepping doesn't work at all when you are running over VPI? | 05:45 |
| @stekern | for me on my de0_nano, neither breakpoints nor single stepping seems to work | 06:28 |
| @stekern | with a fresher orpsoc build than what was on the board things works better | 06:45 |
| @stekern | I'll rebuild with the old debug if, then I should be able to run signaltap and openocd and or_debug_proxy | 06:48 |
| @stekern | ok, so single stepping over a jump with or_debug_proxy works, with openocd it doesn't | 07:07 |
| @stekern | (which I believe is what we have seen before) | 07:07 |
| @stekern | hmm, but setting a breakpoint at a jump instruction and then press continue seems to discard the jump | 07:12 |
| @stekern | I edited _franck_s testcode a bit http://pastie.org/5170396 | 07:14 |
| @stekern | so setting a breakpoint at 0x188 and hitting c will make the program run to 0x12c | 07:15 |
| @stekern | with or_debug_proxyu | 07:15 |
| @stekern | ahh, but this works with openocd.... | 07:17 |
| _franck_ | yes the c thing works, not stepi | 08:49 |
| _franck_ | stekern: "do I understand your e-mail correct......" : yes | 08:51 |
| @stekern | odd | 08:52 |
| @stekern | I wonder if it's a bug in openocd, or a bug in the rtl that openocd tickles | 08:53 |
| @stekern | I mean, the "stepi ignore jumps" bug | 08:54 |
| _franck_ | I thin k we should fix the bug I can see on the VPI then, see how it goes in openocd | 09:01 |
| @stekern | yes, that sounds reasonable | 09:02 |
| _franck_ | did you try GDB over VPI too see the strange behavior ? | 09:02 |
| @stekern | I don't think I've ever trued running GDB over VPI, how do you do that? | 09:03 |
| _franck_ | make rtl-tests TEST=or1200-led VPI=1 VCD=1 | 09:04 |
| _franck_ | the you connect to :50002 with your gdb | 09:04 |
| _franck_ | as simple as that | 09:04 |
| _franck_ | that's why I'm using it :) | 09:04 |
| @stekern | thanks | 09:13 |
| @stekern | it doesn't seem to work at all | 09:16 |
| _franck_ | :( ? | 09:17 |
| @stekern | I load my testcode, and then run disas 0x100,0x130 | 09:17 |
| @stekern | this is what I get: | 09:17 |
| @stekern | http://pastie.org/5170662 | 09:18 |
| @stekern | maybe I should say, "doesn't seem to work *well* at all" | 09:19 |
| @stekern | obviously it's somewhat working | 09:19 |
| _franck_ | I didn't try disas :) | 09:20 |
| @stekern | the instructions in the disas is flipped | 09:20 |
| @stekern | s/is/are | 09:20 |
| _franck_ | just break point the jump *0x100 | 09:20 |
| @stekern | (gdb) x 0x100 | 09:20 |
| @stekern | 0x100: 0x00916018 | 09:20 |
| _franck_ | ok go to work now | 09:20 |
| @stekern | vs: 100: 18 60 91 00 l.movhi r3,0x9100 | 09:21 |
| @stekern | yeah, me too | 09:21 |
| @stekern | (or rather, gotta get back to work) | 09:21 |
| @stekern | juliusb: I recall you mentioning something about "gc-sections, we need that" during the openrisc meeting | 09:40 |
| @stekern | is there something that is broken when running: -ffunction-sections -Wl,--gc-sections | 09:40 |
| @stekern | (I meant to ask about this then, but conversation went in some other direction and I've forgot about until now) | 09:41 |
| @jeremybennett | stekern: we don't have --gc-sections implemented for our binutils. | 10:06 |
| @jeremybennett | The tests fail, because the way DejaGnu is set up just looks to see if ld -help includes --gc-sections (it does), not whether it is functional. | 10:07 |
| @jeremybennett | simoncook has been looking at this for another architecture and might be able to help. | 10:07 |
| @jeremybennett | Do you actually need --gc-sections, or do you need the tests to rigorously detect that it is not implemented, so the test is not run? | 10:08 |
| @stekern | I don't "need it" for anything ;) | 10:09 |
| @stekern | but lurking around other targets, they don't seem to do anything fancier than we are in this regard | 10:10 |
| @stekern | and -ffunction-sections -Wl,--gc-sections works for my very trivial testcase | 10:11 |
| @stekern | http://pastie.org/5170792 | 10:14 |
| @stekern | (me adding a elf_backend_can_gc_sections to bfd *might* have something to do with this) | 10:31 |
| @stekern | but really, all I do in or1k_elf_gc_sweep_hook is related to the PIC stuff | 10:32 |
| @jeremybennett | stekern: I didn't realize we had any --gc-sections functionality. This is simoncook's area of expertise. He's not in yet, but I'll get him to take a look later. | 11:29 |
| @stekern | jeremybennett: I didn't realize there was a point in time when we lacked the functionality completely (i.e. ld complains with a: "Warning: gc-sections option ignored") | 12:23 |
| @juliusb | --gc-sections though is a very useful thing for embedded platforms, I was considering looking into it | 12:24 |
| @juliusb | afaik it removes unneeded functions | 12:24 |
| @stekern | actually, it wasn't even me that added the: #define elf_backend_can_gc_sections 1 | 12:26 |
| @stekern | it was peter | 12:26 |
| @stekern | but he added it when he imported juliusb binutils | 12:31 |
| @stekern | juliusb: yes, it removes unneeded functions (as you can see in the trivial testcase I pastie.orged) | 12:33 |
| simoncook | ls | 12:33 |
| simoncook | wait... stop typing in wrong terminal | 12:33 |
| simoncook | hello btw | 12:33 |
| @stekern | simoncook: hi ;) | 12:33 |
| @stekern | juliusb: now we just have to backtrack how we gained this functionality, since it was lacking in the or32-*-* toolchains ;) | 12:34 |
| @jeremybennett | stekern: juliusb: If you set that #define, you do need to make sure you have certain functionality in the ELF backend! It's not magic. | 12:36 |
| @stekern | jeremybennett: everything in the gnu toolchain works by magic, black magic! I thought you knew that :) | 12:39 |
| @stekern | more seriously, apart from implementing elf_backend_gc_mark_hook and elf_backend_gc_sweep_hook (which we do), I don't see other targets doing much more | 12:44 |
| @stekern | I might be missing something though, hence bringing it up | 12:44 |
| @stekern | juliusb: I'm confused by this commit: https://github.com/juliusbaxter/binutils-or1k/commit/f7069d5fdd575fab866a7729fd3d2566c487794a | 12:50 |
| simoncook | those two seem to be the main two functions to get that working, I thought I saw some targets using implementing other functions as well, but quickly searching through binutils I can't seem to find them | 12:52 |
| @stekern | juliusb: what did you base your elf32-or1k.c on? | 12:53 |
| @stekern | and why is there a elf32-openrisc.c _and_ a elf32-or32.c in svn://gnu-stable/binutils-2.20.1/bfd/ | 12:55 |
| @stekern | if I understand this correctly, juliusb based elf32-or1k.c on elf32-openrisc.c, but elf32-or32.c is the one that is used in binutils-2.20.1, right? | 12:58 |
| @stekern | (elf32-openrisc.c has elf_backend_can_gc_sections defined) | 12:58 |
| @jeremybennett | elf32-or32.c is more up to date. I think we dealt with various issues we encountered when doing GCC 4.5.1. | 12:59 |
| @stekern | fair enough, but what's the reason there were two files there in the first place? | 13:02 |
| @stekern | + the more recent changes to elf32-or32.c seems already be in elf32-openrisc.c | 13:26 |
| @stekern | +to | 13:26 |
| @stekern | (it uses rela and the howto's are as in the final elf32-or32.c) | 13:26 |
| @stekern | hmm, I see both are upstream... how did that happen? | 13:40 |
| @stekern | looks like Ivan Guzvinec decided to send a patch that adds elf32-or32.c around one year after Johan Rydberg had submitted elf32-openrisc.c | 13:48 |
| @stekern | what a mess... | 13:49 |
| @stekern | looks like we have that cleaned up in or1k now (thanks to juliusb) | 13:49 |
| @stekern | and peter | 13:49 |
| @stekern | no, just juliusb :) | 13:53 |
| @stekern | hard to follow the changes... | 13:53 |
| @juliusb | one is automatically generated isn't it? | 16:19 |
| @juliusb | elf32-openrisc.c was the one with CGEN bits in it, or was wholly generated by CGEN? | 16:20 |
| @stekern | nah, none is automatically generated | 16:23 |
| @juliusb | hmm | 16:23 |
| @stekern | but probably the one that was coupled with cgen | 16:23 |
| @stekern | I wonder what the motivation for elf32-or32.c was | 16:24 |
| @juliusb | certainly, Johan Rydberg's stuff was all to do with the CGEN-based frontend things | 16:24 |
| @juliusb | the elf32-or32.c supported _all_ of the or1k instructions | 16:24 |
| @juliusb | l.custs, lv.xxx | 16:24 |
| @juliusb | all of the floating point | 16:24 |
| @juliusb | CGEN never got that close | 16:24 |
| @stekern | ah, ok | 16:25 |
| @juliusb | that's my understanding, and those Slovenian guys did a whole tool chain from scratch\ | 16:25 |
| @juliusb | almost entirely separate from anything Johan Rydberg did | 16:25 |
| @stekern | ok, that "makes sense" (the explanation, not the seperate work) | 16:27 |
| @stekern | and then it of course makes sense that you continued ontop of Rydbergs work (since that was the CGEN work) | 16:28 |
| @juliusb | yep | 16:34 |
| @juliusb | it is based on the usual way you build an elf32-xxx.c for your arch from CGEN, afaict | 16:34 |
| @juliusb | but the CGEN-based one is missing tings, like the nice disassembly function, I think | 16:36 |
| @stekern | hmm, are you thinking about the opcode libraries? | 16:52 |
| @juliusb | I'd need to look again but there was some easier way for doing disassembly with the or32 version. Will need to look at it again to substantiate what I'm going on about :P | 20:24 |
| @stekern | Did we have the mor1kx-devenv working against your binutils repo, or is that something I have dreamt? | 20:26 |
| @stekern | I mean through your or1ktrace stuff? | 20:27 |
| @stekern | anyways, if you want to build libbfd.so and libopcodes.so, you'll need to configure or1k-src with --enable-shared | 20:42 |
| @stekern | the libs and include files will end up in /opt/or1k/x86_64-unknown-linux-gnu/or1k-linux/ | 20:43 |
| @stekern | when done with the or1k-linux toolchain | 20:44 |
| @stekern | which should make configuring or1ktrace a lot cleaner than what you have now ;) | 20:45 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!