IRC logs for #openrisc Friday, 2012-11-02

@stekernnice job _franck_!05:35
@stekerndo I understand your e-mail correct, that single stepping doesn't work at all when you are running over VPI?05:45
@stekernfor me on my de0_nano, neither breakpoints nor single stepping seems to work06:28
@stekernwith a fresher orpsoc build than what was on the board things works better06:45
@stekernI'll rebuild with the old debug if, then I should be able to run signaltap and openocd and or_debug_proxy06:48
@stekernok, so single stepping over a jump with or_debug_proxy works, with openocd it doesn't07:07
@stekern(which I believe is what we have seen before)07:07
@stekernhmm, but setting a breakpoint at a jump instruction and then press continue seems to discard the jump07:12
@stekernI edited _franck_s testcode a bit
@stekernso setting a breakpoint at 0x188 and hitting c will make the program run to 0x12c07:15
@stekernwith or_debug_proxyu07:15
@stekernahh, but this works with openocd....07:17
_franck_yes the c thing works, not stepi08:49
_franck_stekern: "do I understand your e-mail correct......" : yes08:51
@stekernI wonder if it's a bug in openocd, or a bug in the rtl that openocd tickles08:53
@stekernI mean, the "stepi ignore jumps" bug08:54
_franck_I thin k we should fix the bug I can see on the VPI then, see how it goes in openocd09:01
@stekernyes, that sounds reasonable09:02
_franck_did you try GDB over VPI too see the strange behavior ?09:02
@stekernI 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=109:04
_franck_the you connect to :50002 with your gdb09:04
_franck_as simple as that09:04
_franck_that's why I'm using it :)09:04
@stekernit doesn't seem to work at all09:16
_franck_:( ?09:17
@stekernI load my testcode, and then run disas 0x100,0x13009:17
@stekernthis is what I get:09:17
@stekernmaybe I should say, "doesn't seem to work *well* at all"09:19
@stekernobviously it's somewhat working09:19
_franck_I didn't try disas :)09:20
@stekernthe instructions in the disas is flipped09:20
_franck_just break point the jump *0x10009:20
@stekern(gdb) x 0x10009:20
@stekern0x100:  0x0091601809:20
_franck_ok go to work now09:20
@stekernvs:  100:   18 60 91 00     l.movhi r3,0x910009:21
@stekernyeah, me too09:21
@stekern(or rather, gotta get back to work)09:21
@stekernjuliusb: I recall you mentioning something about "gc-sections, we need that" during the openrisc meeting09:40
@stekernis there something that is broken when running: -ffunction-sections -Wl,--gc-sections09: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
@jeremybennettstekern: we don't have --gc-sections implemented for our binutils.10:06
@jeremybennettThe 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
@jeremybennettsimoncook has been looking at this for another architecture and might be able to help.10:07
@jeremybennettDo 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
@stekernI don't "need it" for anything ;)10:09
@stekernbut lurking around other targets, they don't seem to do anything fancier than we are in this regard10:10
@stekernand -ffunction-sections -Wl,--gc-sections works for my very trivial testcase10:11
@stekern(me adding a elf_backend_can_gc_sections to bfd *might* have something to do with this)10:31
@stekernbut really, all I do in or1k_elf_gc_sweep_hook is related to the PIC stuff10:32
@jeremybennettstekern: 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
@stekernjeremybennett: 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 it12:24
@juliusbafaik it removes unneeded functions12:24
@stekernactually, it wasn't even me that added the: #define elf_backend_can_gc_sections 112:26
@stekernit was peter12:26
@stekernbut he added it when he imported juliusb binutils12:31
@stekernjuliusb: yes, it removes unneeded functions (as you can see in the trivial testcase I pastie.orged)12:33
simoncookwait... stop typing in wrong terminal12:33
simoncookhello btw12:33
@stekernsimoncook: hi ;)12:33
@stekernjuliusb: now we just have to backtrack how we gained this functionality, since it was lacking in the or32-*-* toolchains ;)12:34
@jeremybennettstekern: 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
@stekernjeremybennett: everything in the gnu toolchain works by magic, black magic! I thought you knew that :)12:39
@stekernmore 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 more12:44
@stekernI might be missing something though, hence bringing it up12:44
@stekernjuliusb: I'm confused by this commit:
simoncookthose 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 them12:52
@stekernjuliusb: what did you base your elf32-or1k.c on?12:53
@stekernand why is there a elf32-openrisc.c _and_ a elf32-or32.c in svn://gnu-stable/binutils-2.20.1/bfd/12:55
@stekernif 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
@jeremybennettelf32-or32.c is more up to date. I think we dealt with various issues we encountered when doing GCC
@stekernfair 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.c13:26
@stekern(it uses rela and the howto's are as in the final elf32-or32.c)13:26
@stekernhmm, I see both are upstream... how did that happen?13:40
@stekernlooks like Ivan Guzvinec decided to send a patch that adds elf32-or32.c around one year after Johan Rydberg had submitted elf32-openrisc.c13:48
@stekernwhat a mess...13:49
@stekernlooks like we have that cleaned up in or1k now (thanks to juliusb)13:49
@stekernand peter13:49
@stekernno, just juliusb :)13:53
@stekernhard to follow the changes...13:53
@juliusbone is automatically generated isn't it?16:19
@juliusbelf32-openrisc.c was the one with CGEN bits in it, or was wholly generated by CGEN?16:20
@stekernnah, none is automatically generated16:23
@stekernbut probably the one that was coupled with cgen16:23
@stekernI wonder what the motivation for elf32-or32.c was16:24
@juliusbcertainly, Johan Rydberg's stuff was all to do with the CGEN-based frontend things16:24
@juliusbthe elf32-or32.c supported _all_ of the or1k instructions16:24
@juliusbl.custs, lv.xxx16:24
@juliusball of the floating point16:24
@juliusbCGEN never got that close16:24
@stekernah, ok16:25
@juliusbthat's my understanding, and those Slovenian guys did a whole tool chain from scratch\16:25
@juliusbalmost entirely separate from anything Johan Rydberg did16:25
@stekernok, that "makes sense" (the explanation, not the seperate work)16:27
@stekernand then it of course makes sense that you continued ontop of Rydbergs work (since that was the CGEN work)16:28
@juliusbit is based on the usual way you build an elf32-xxx.c for your arch from CGEN, afaict16:34
@juliusbbut the CGEN-based one is missing tings, like the nice disassembly function, I think16:36
@stekernhmm, are you thinking about the opcode libraries?16:52
@juliusbI'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 :P20:24
@stekernDid we have the mor1kx-devenv working against your binutils repo, or is that something I have dreamt?20:26
@stekernI mean through your or1ktrace stuff?20:27
@stekernanyways, if you want to build and, you'll need to configure or1k-src with --enable-shared20:42
@stekernthe libs and include files will end up in /opt/or1k/x86_64-unknown-linux-gnu/or1k-linux/20:43
@stekernwhen done with the or1k-linux toolchain20:44
@stekernwhich should make configuring or1ktrace a lot cleaner than what you have now ;)20:45

Generated by 2.15.2 by Marius Gedminas - find it at!