Hi David,
> I was thinking that you could add the label after the trap and
> then use '.long 1b-4'. But you'd have to put the asm outside the
> conditional - so that wouldn't work if the condition was more
> complicated and the trap had to be out of line.
>
> If the trap is out of line, then it could be a long way from
> the surrounding code block - so a label 'nearby' in the C isn't
> any use.
>
> With fix sized instructions the .text segment of the object files
> could be scanned for trap instructions.
I tried something similar a while ago and the 1b-4 trick worked for
95%+ of cases but we did end up with out of line traps. I hacked
something up to look for an example, tagging the start and the end of a
BUG_ON, and seeing if the trap was in fact out of line:
asm volatile("1:\n");
if (x)
__builtin_trap();
asm volatile("2:\n");
And this one popped in arch/powerpc/platforms/powernv/pci-ioda.c:
1:
ld 9,0(29)
rlwinm. 8,9,0,29,30
beq- 0,.L287
2:
...
.L287:
trap
You could follow branches and look for the trap, but I'm sure you could
construct things that would be very hard to automatically parse, eg
multiple back to back BUG_ON()'s. At that point I figured some gcc help
would be nice :)
Anton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
