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
> On Tue, Aug 20, 2013 at 02:02:11PM +0930, Alan Modra wrote:
> > On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
> > > address of the trap instruction for our bug exception table. Maybe
> > > we need a gcc builtin in which we can get a label on the trap
> > > instruction. Would th
On Tue, Aug 20, 2013 at 02:02:11PM +0930, Alan Modra wrote:
> On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
> > address of the trap instruction for our bug exception table. Maybe
> > we need a gcc builtin in which we can get a label on the trap
> > instruction. Would that be poss
On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
> address of the trap instruction for our bug exception table. Maybe
> we need a gcc builtin in which we can get a label on the trap
> instruction. Would that be possible?
Not your actual _EMIT_BUG_ENTRY, but something like this ough
On Tue, 2013-08-20 at 12:37 +1000, Anton Blanchard wrote:
>0: 00 00 23 a1 lhz r9,0(r3)
>4: 01 00 60 38 li r3,1
>8: 20 00 a9 0c twlgei r9,32
>c: 20 00 80 4e blr
>
> Nice! I remember chasing this down before and the issue is we need the
> address of
Hi,
I noticed our BUG_ON macros were taking a large number of instructions.
I've built a testcase to analyse it:
#if defined(ASMBUG)
#define BUG_ON(x) do { \
__asm__ __volatile__("tdnei %0,0\n" : : "r" ((long)(x))); \
} while (0)
#elif defined(BUILTIN)
#define BUG_ON(x) do { \
