On Sat, 21 May 2016, James Hogan wrote: > >More importantly the use of `.insn' prevents execution from going > >astray > >if there's a label being jumped to at the handcoded instruction. > > Right. in my builds i couldn't find any examples of this happening, only > relative branches (the only diff when adding .insn seemed to be objdump > -d printing as microMIPS, but tbh i didn't compare data sections), but > perhaps it could still happen with a different configuration or > toolchain? It would have to be a JAL instruction (relaxed to JALX as necessary) or one of the register jumps. The J instruction would cause an assembly or link error, depending on the symbol binding (a global or weak symbol may yet be preempted), as there's no way to switch modes with a direct jump. Branches however currently ignore the ISA bit, which I consider a bug, as it makes binutils silently produce broken code in regular MIPS and microMIPS interlinking if a branch target turns out to be the other ISA. Therefore I have a binutils patch in the works to correct this problem and make GAS and LD, as applicable, diagnose unsupported mode switches with branches and fail, but it will make `.insn' annotation even more necessary for handcoded machine code and other such odd cases. I would have actually pushed this change this week already if not for a microMIPS JALX encoding bug I've encountered, which would require me to write nonsensical code if not handled first. That bug has now been fixed, so I expect to push said branch diagnostics sometime next week. You may want try building with binutils master afterwards to see if any further cases of missing `.insn' annotation have been revealed. FAOD (of the other readers) none of this affects regular MIPS kernel builds. It's all about microMIPS code, so there's no concern about toolchain compatibility with regular (classic) MIPS kernel configurations. Maciej
