Re: [PATCH] Put the BUG __FILE__ and __LINE__ info out of line

From: Andrew Morton
Date: Thu Sep 28 2006 - 03:03:12 EST

On Wed, 27 Sep 2006 23:49:49 -0700
Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

> Andrew Morton wrote:
> > hm. Bigger vmlinux, smaller .text.
> >
> Yep.
> > It means that we'll hit handle_BUG with that extra EIP pushed on the stack.
> > What does that do to the stack trace, and to the unwinder?
> >
> Dunno. I was hoping Andi would pop up with the appropriate CFI gunk, if
> necessary. But the reason for making it a call was to make it as
> unwindable as possible.
> > It'll also muck up the displayed EIP, not that that matters a lot (well, it
> > might matter a bit if the BUG is in an inlined function).
> >
> > We could get the correct EIP by fishing it off the stack (and subtracting
> > five from it?)
> >
> Yes, that's possible.
> > Or we could assume that BUG doesn't return (it doesn't) and make that call
> > a jmp. But then we'd really lose the EIP.
> Right. Or it could save the EIP along with the line and filename.

Plan #17 is to just put the BUG inline and then put the EIP+file*+line into
a separate section, then search that section at BUG time to find the record
whose EIP points back at this ud2a.

It's a bit messy for modules, but it minimises the .text impact and keeps
disassembly happy, no?

And if done right it can probably be used by other architectures.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at