IRC logs for #openrisc Friday, 2012-08-17

Jiamorning all, how can I `jtag` RTL in golden by using OpenOCD or other sw?09:56
JiaRTL verification env10:09
stekernnever heard of10:13
stekerngot a reference?10:15
Jia`debug` the jtag feature in RTL10:16
stekernyes but a reference to 'golden'10:17
stekernwhat is it?10:17
Jiaa system verilog verification env10:18
stekerngoogle doesn't give me anything useful when searching 'system verilog golden'10:20
Jiathey call it `golden`, so...10:22
stekernwho are "they"?10:22
Jiathe RTL coder...10:23
stekernand who is that?10:24
Jiaguys in my company...10:24
stekernso perhaps 'golden' is something that only exists inside your company?10:26
Jiamaybe, I think10:27
jeremybennettIs your RTL using "golden" in the sense of the definitive reference version of the RTL. It's often used to mean the RTL that is/was used to tape out the chip10:45
jeremybennettTypically you are not allowed to change it. So any problems with tools for example have to be dealt with by fixing the tool.10:46
stekernyay, I think I've managed to hack or1k-bfd into producing shared libraries that has a resemblence of being sane10:53
jeremybennettExcellent. Will you post a patch to the mailing list, so we can review and put it into the master SVN copy.10:54
stekernoh, I'm far from done with it :)10:54
stekernbut it's a first step10:55
stekernI've got relocation of _GLOBAL_OFFSET_TABLE_ working, and loading a reference to a symbol with an offset to .got works as well10:57
stekernI still need to get my head wrapped around how the plt works/should work10:59
stekernand I will of course need a functional dynamic loader in uclibc to be able to test it11:00
jeremybennettHave you followed the ideas on the Wiki for how to do the relocations? IIRC Joern and Giovanni had come up with that as something that would fit will with GCC.11:01
jeremybennettYou can always test that you can statically link dynamic objects even if you don't have a dynamic loader.11:02
stekernyou mean this page, right?
jeremybennettThat's the one.11:03
jeremybennettI see it doesn't actually mention the relocations needed - my memory is getting worse :(11:04
jeremybennettBut it does have ideas on GOT and PLT.11:04
stekernmy got pointer loading looks like this right now:
stekernI'm not sure I understand what you meant by "statically link dynamic objects"?11:07
stekernor yes, I do :)11:08
stekernor actually, no...11:10
stekernplease explain =)11:11
jeremybennettI am at the boundaries of my own knowledge, but I believe the ordinary static linker, ld, can be used to link dynamic objects, so you can use that as a way to test your stuff before you have a dynamic loader11:33
jeremybennettIt would be good to add your GOT understanding to the Wiki page. I know Joern is snowed under with work at the moment, but perhaps Giovanni can help11:34
stekernhmm, I can of course link my main executable with the .o of my "library", that is actually very good advice, I think everything I've got so far can be tested that way11:53
-!- mbuf` is now known as mbuf11:55
stekernas always, I'm mostly doing this to learn: my understanding about this was 0 a week ago, but I'm slowly advancing. When I got a clear picture how everything actually is put together, then I can put down some notes on the wiki11:55
jeremybennettSame as the rest of us with this stuff!12:42
stekernI know :) I just wanted to point out that I'm not in a position to write anything down on the wiki just yet12:44
stekernwow! it actually works!12:46
stekernthe statically linked dynamic library12:47
stekernthis is the test "library":
stekernwhich I link to the main exe: int main(void) { test(); }12:49
stekern(the sharp-eyed reader will notice that I needed to fix a bug in the got pointer load) =)12:51
stekernI'd like to get rid of the gotpchi() and be able to just do hi(_GLOBAL_OFFSET_TABLE), but that seems to clash a bit with the idea of using the cgen-generated assembler12:53
stekernmaybe the gotpchi is just fine12:54
stekernanother note; r10 as is mentioned on seems to be used as a pointer to current_thread_info in linux13:25
juliusb_stekern: regarding something you mentioned a few days ago regarding the instructions with immediates preceeding instructions which use them - that's an interesting question. I'm also tempted to investigate instructions which alter the behaviour of the next one somehow. If you were to allow exceptions in between the instructions you would then have to have some state in the processor which is maintained (saved and resto13:28
juliusb_because that could be very useful, in 16-bit instructions, you could have a version which takes the result register of the previous instruction, therefore you rely on that register number being stored in the processor somewhere13:29
stekernjuliusb_: yes, but I'd rather have it interpreted kind of as a 64-bit instruction13:29
stekerni.e. nothing can happen in between13:30
juliusb_hmm, yes, or you make it so that the PC on exceptions only goes back to the first of the two13:30
stekernyes, that could would work too13:31
juliusb_but then, you need to make sure that it doesn't matter if the first instruction repeats13:31
juliusb_ie, if you repeat it you will get the same outcome13:31
juliusb_so incrementing a register wouldn't be OK13:31
stekernfor the imm case, it should be fine13:31
stekernthe reason I prefer not to save away states is that I think we should make sure that nested interrupts will work13:33
juliusb_I agree13:34
juliusb_it's just easier to make sure that first instruction is repeatable13:34
juliusb_repeating some ALU instruction is less work than saving and restoring state13:34
stekernwhat is the huge gain in 16-bit insns though? wouldn't a 32-bit version that does the same thing make more sense?13:41
juliusb_it depends, if you can save chewing up opcode space and have the same opcode work for both versions (with immediate and without) then that's better14:00
stekerntrue true14:02
stekernhmm, I think I'm remotely starting to understand the PLT things, but I'm not 100% sure I understand the benefit of calling through .plt instead of doing the load-in-to-register-from-got and l.jalr as in my test library15:19
stekernexcept that you move the decision if the call actually should be PIC or not to the linker from the compiler in the call through .plt case15:20
stekerni.e. the linker could decide to call a function straight instead of going through .plt15:22
stekernah, and lazy binding (if I have understood that correctly) will not work if not calling through .plt15:27

Generated by 2.15.2 by Marius Gedminas - find it at!