On Mon, 11 Feb 2002, Andrew Morton wrote:
> Hugh Dickins wrote:
> >
> > 1. I'd be sorry to see it go in as is: you haven't noticed how this
> > looks to a disassembler: not pretty! I don't see an alternative
> > to wasting some more bytes: putting "push"es in front of line and
> > file? or is there one instruction (some "mov"?) to encompass both
> > line and file together?
>
> This will also confound ksymoops when it parses the opcode
> dump. But we know the file-and-line, so that doesn't seem
> very important.
Well, it's not very important if it's immediately obvious why the
BUG() on that source line should fire. But in general, BUG()s are
catching problems that are not immediately obvious.
Very often we want to peer at the registers, work out exactly what's
happening. That is precisely why you're making these changes. Maybe
your in-head disassembler is better than objdump, but I need objdump
or ksymoops or kdb to make sense of what's there.
Of course, the nonsense comes _after_ the BUG(): but once you have
several BUG()s in succession, it can be hard even to find subsequent
"ud2a"s - in __free_pages_ok, I see "08 0f or %cl,(%edi)
0b 4c 00 7c or 0x7c(%eax,%eax,1),%ecx" and suspect that
there's really a "0f 0b ud2a" hidden in there.
The BUG() info is there to help debugging, it should not be obscuring
the code. I guess it would be easy to (mis)teach ksymoops and kdb
that "ud2a" is actually a seven-byte instruction, but not objdump.
> If the unpretty disassembler output is a problem, we could go
> back to your do_BUG code if CONFIG_DEBUG_BUGVERBOSE=y?
I don't care for that, I really like that the option should go (or be
sidelined to mean something else, which only affects a few places,
as you have it), given your triumph in cutting down its overhead.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:43 EST