Put the BUG __FILE__ and __LINE__ info out of line
in [Kernel]
|
Prev: Network problem with 2.6.18-mm1 ?
Next: 2.6.18-mm2
From: Andrew Morton on 28 Sep 2006 02:40 On Wed, 27 Sep 2006 23:00:03 -0700 Jeremy Fitzhardinge <jeremy(a)goop.org> wrote: > When CONFIG_DEBUG_BUGVERBOSE is enabled, the embedded file and line > information makes a disassembler very unhappy, because it tries to > parse them as instructions (it probably makes the CPU's instruction > decoder a little unhappy too). > > This patch moves them out of line, and calls the ud2 from the code - > the call makes sure the original %eip is available on the top of the > stack. The result is a happy disassembler, with no loss of debugging > information. > > Signed-off-by: Jeremy Fitzhardinge <jeremy(a)goop.org> > > -- > arch/i386/kernel/vmlinux.lds.S | 2 ++ > include/asm-i386/bug.h | 13 ++++++++----- > 2 files changed, 10 insertions(+), 5 deletions(-) > > diff -r 1d29394927f3 arch/i386/kernel/vmlinux.lds.S > --- a/arch/i386/kernel/vmlinux.lds.S Tue Sep 26 01:20:38 2006 -0700 > +++ b/arch/i386/kernel/vmlinux.lds.S Wed Sep 27 22:18:23 2006 -0700 > @@ -27,6 +27,8 @@ SECTIONS > _text = .; /* Text and read-only data */ > .text : AT(ADDR(.text) - LOAD_OFFSET) { > *(.text) > + __bugs = .; > + *(.text.bugs) > SCHED_TEXT > LOCK_TEXT > KPROBES_TEXT > diff -r 1d29394927f3 include/asm-i386/bug.h > --- a/include/asm-i386/bug.h Tue Sep 26 01:20:38 2006 -0700 > +++ b/include/asm-i386/bug.h Wed Sep 27 18:59:41 2006 -0700 > @@ -11,11 +11,14 @@ > #ifdef CONFIG_BUG > #define HAVE_ARCH_BUG > #ifdef CONFIG_DEBUG_BUGVERBOSE > -#define BUG() \ > - __asm__ __volatile__( "ud2\n" \ > - "\t.word %c0\n" \ > - "\t.long %c1\n" \ > - : : "i" (__LINE__), "i" (__FILE__)) > +#define BUG() \ > + __asm__ __volatile__("call 1f\n" \ > + ".section .text.bugs\n" \ > + "1:\tud2\n" \ > + "\t.word %c0\n" \ > + "\t.long %c1\n" \ > + ".previous\n" \ > + : : "i" (__LINE__), "i" (__FILE__)) > #else > #define BUG() __asm__ __volatile__("ud2\n") > #endif hm. Bigger vmlinux, smaller .text. 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? 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?) 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 28 Sep 2006 03:00 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. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 28 Sep 2006 03:10 On Wed, 27 Sep 2006 23:49:49 -0700 Jeremy Fitzhardinge <jeremy(a)goop.org> 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 28 Sep 2006 03:20 On Wed, Sep 27, 2006 at 11:00:03PM -0700, Jeremy Fitzhardinge wrote: > When CONFIG_DEBUG_BUGVERBOSE is enabled, the embedded file and line > information makes a disassembler very unhappy, because it tries to > parse them as instructions (it probably makes the CPU's instruction > decoder a little unhappy too). > > This patch moves them out of line, and calls the ud2 from the code - > the call makes sure the original %eip is available on the top of the > stack. The result is a happy disassembler, with no loss of debugging > information. x86-64 has a much better solution for this. Please copy that one. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 28 Sep 2006 03:20
> 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. The way x86-64 solved it was to turn the inline code into valid instructions. This can be done with two additional bytes. IMHO that's the right solution for the problem on i386 too -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |