IRC logs for #openrisc Friday, 2012-07-20

-!- _franck__ is now known as _franck_10:29
stekernwhich l.nop is it that prints the value in r3?14:44
stekernl.nop 114:46
jeremybennettI think that's exit. Hold on while I look up.14:49
jeremybennettl.nop 4.14:51
jeremybennettHere's the header section from Or1ksim14:51
jeremybennett#define NOP_NOP          0x0000      /* Normal nop instruction */14:51
jeremybennett#define NOP_EXIT         0x0001      /* End of simulation */14:51
jeremybennett#define NOP_REPORT       0x0002      /* Simple report */14:51
jeremybennett#define NOP_PUTC         0x0004      /* JPB: Simputc instruction */14:51
jeremybennett#define NOP_CNT_RESET    0x0005     /* Reset statistics counters */14:51
jeremybennett#define NOP_GET_TICKS    0x0006     /* JPB: Get # ticks running */14:51
jeremybennett#define NOP_GET_PS       0x0007      /* JPB: Get picosecs/cycle */14:51
jeremybennett#define NOP_TRACE_ON     0x0008      /* Turn on tracing */14:51
jeremybennett#define NOP_TRACE_OFF    0x0009      /* Turn off tracing */14:51
jeremybennett#define NOP_RANDOM       0x000a      /* Return 4 random bytes */14:51
jeremybennett#define NOP_OR1KSIM      0x000b      /* Return non-zero if this is Or1ksim */14:51
jeremybennett3 is PRINTF, which is obsolete14:51
stekernok, so it's l.nop 2 I want14:54
stekernI want to print the value of r3, that's what it doesn, right?14:54
stekernah, those trace nops might come in handy as well14:55
stekern(my current trace is 800MB)14:58
jeremybennettYes - that'w what you want.15:32
jeremybennettIIRC Joern put quite a nice trace system into Or1ksim, based on what was done for the Renesas SH family.15:32
jeremybennettYou might want to take code from that. Very good one line per instruction trace of execution.15:33
jeremybennettIf that is what you are trying to do of course!15:33
stekernI try to print r3 in a critical place where a printk isn't suitable ;)15:36
stekernthe trace note was unrelated to what I'm doing at the moment, I just hadn't noticed that there was such nops available15:38
stekern(and it is or1ksim I'm using)15:39
stekernhmm, interesting, I unintentionally changed the order of called-save registers in my second to last commit, that completely changed the behaviour of the bug I'm examining18:42
stekernprobably is related, the thing I'm seeing is that the address to the struct sent to wait_for_completion() is off by four from the struct that is later completed18:47
stekernthis debugging is fun ;) makes me look at places in the linux kernel I probably would never bother to examing otherwise18:48
* derRichard knows this feeling18:50

Generated by 2.15.2 by Marius Gedminas - find it at!