| Jia | morning all, how can I `jtag` RTL in golden by using OpenOCD or other sw? | 09:56 |
|---|---|---|
| stekern | golden? | 10:08 |
| Jia | RTL verification env | 10:09 |
| stekern | never heard of | 10:13 |
| Jia | thx | 10:13 |
| stekern | got a reference? | 10:15 |
| Jia | `debug` the jtag feature in RTL | 10:16 |
| stekern | yes but a reference to 'golden' | 10:17 |
| stekern | what is it? | 10:17 |
| Jia | a system verilog verification env | 10:18 |
| stekern | google doesn't give me anything useful when searching 'system verilog golden' | 10:20 |
| Jia | they call it `golden`, so... | 10:22 |
| stekern | who are "they"? | 10:22 |
| Jia | the RTL coder... | 10:23 |
| stekern | and who is that? | 10:24 |
| Jia | guys in my company... | 10:24 |
| stekern | ok | 10:25 |
| stekern | so perhaps 'golden' is something that only exists inside your company? | 10:26 |
| Jia | maybe, I think | 10:27 |
| jeremybennett | Is 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 chip | 10:45 |
| jeremybennett | Typically 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 |
| stekern | yay, I think I've managed to hack or1k-bfd into producing shared libraries that has a resemblence of being sane | 10:53 |
| jeremybennett | Excellent. Will you post a patch to the mailing list, so we can review and put it into the master SVN copy. | 10:54 |
| stekern | oh, I'm far from done with it :) | 10:54 |
| stekern | but it's a first step | 10:55 |
| stekern | I've got relocation of _GLOBAL_OFFSET_TABLE_ working, and loading a reference to a symbol with an offset to .got works as well | 10:57 |
| stekern | I still need to get my head wrapped around how the plt works/should work | 10:59 |
| stekern | and I will of course need a functional dynamic loader in uclibc to be able to test it | 11:00 |
| jeremybennett | Have 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 |
| jeremybennett | You can always test that you can statically link dynamic objects even if you don't have a dynamic loader. | 11:02 |
| stekern | you mean this page, right? http://opencores.org/or1k/OpenRISC_PIC | 11:02 |
| jeremybennett | That's the one. | 11:03 |
| jeremybennett | I see it doesn't actually mention the relocations needed - my memory is getting worse :( | 11:04 |
| jeremybennett | But it does have ideas on GOT and PLT. | 11:04 |
| stekern | my got pointer loading looks like this right now: http://pastebin.com/qZRUNkis | 11:06 |
| stekern | I'm not sure I understand what you meant by "statically link dynamic objects"? | 11:07 |
| stekern | or yes, I do :) | 11:08 |
| stekern | or actually, no... | 11:10 |
| stekern | please explain =) | 11:11 |
| jeremybennett | I 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 loader | 11:33 |
| jeremybennett | It 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 help | 11:34 |
| stekern | hmm, 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 way | 11:53 |
| -!- mbuf` is now known as mbuf | 11:55 | |
| stekern | as 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 wiki | 11:55 |
| jeremybennett | Same as the rest of us with this stuff! | 12:42 |
| stekern | I know :) I just wanted to point out that I'm not in a position to write anything down on the wiki just yet | 12:44 |
| stekern | wow! it actually works! | 12:46 |
| stekern | the statically linked dynamic library | 12:47 |
| jeremybennett | Excellent | 12:47 |
| stekern | this is the test "library": http://pastebin.com/fb9Yb8Dm | 12:48 |
| stekern | which 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 |
| stekern | I'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 assembler | 12:53 |
| stekern | maybe the gotpchi is just fine | 12:54 |
| stekern | another note; r10 as is mentioned on http://opencores.org/or1k/OpenRISC_PIC seems to be used as a pointer to current_thread_info in linux | 13: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 resto | 13: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 somewhere | 13:29 |
| stekern | juliusb_: yes, but I'd rather have it interpreted kind of as a 64-bit instruction | 13:29 |
| stekern | i.e. nothing can happen in between | 13:30 |
| juliusb_ | hmm, yes, or you make it so that the PC on exceptions only goes back to the first of the two | 13:30 |
| stekern | yes, that could would work too | 13:31 |
| juliusb_ | but then, you need to make sure that it doesn't matter if the first instruction repeats | 13:31 |
| juliusb_ | ie, if you repeat it you will get the same outcome | 13:31 |
| juliusb_ | so incrementing a register wouldn't be OK | 13:31 |
| stekern | for the imm case, it should be fine | 13:31 |
| juliusb_ | yeah | 13:31 |
| stekern | the reason I prefer not to save away states is that I think we should make sure that nested interrupts will work | 13:33 |
| juliusb_ | I agree | 13:34 |
| juliusb_ | it's just easier to make sure that first instruction is repeatable | 13:34 |
| juliusb_ | repeating some ALU instruction is less work than saving and restoring state | 13:34 |
| stekern | what 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 better | 14:00 |
| stekern | true true | 14:02 |
| stekern | hmm, 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 library | 15:19 |
| stekern | except 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 case | 15:20 |
| stekern | i.e. the linker could decide to call a function straight instead of going through .plt | 15:22 |
| stekern | ah, and lazy binding (if I have understood that correctly) will not work if not calling through .plt | 15:27 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!