Messages in this thread | | | Date | Fri, 10 May 2002 15:58:16 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] BUG() disassembly tweak |
| |
Linus Torvalds wrote: > > On Fri, 10 May 2002, Hugh Dickins wrote: > > > > Could we change the i386 BUG() macro slightly again?
Hugh's patch looks just dandy to me, even though I don't understand the problem ;)
> If it wants to be changed, I'd actually personally prefer it to be changed > to take an explicit string instead of using the filename/linenr at all.
There seem to be two classes of bug report(er)s: the good ones who do a bit of up-front analysis and the less good ones....
I believe that the BUG() macro should be tuned to the less-good ones. Generally, these are folk who take their kernels straight from kernel.org and the line number is not a problem. People who have applied other patches have the experience and knowledge to go digging in the source tree and find which line it was, and to include this in the report.
So.. dunno about others, but I find file-n-line works not too badly.
> The filename/linenr one has the size problem (those absolute file names > are _long_), and sucks when you have slight kernel version skew and > suddenly the information isn't obviously unambiguous at all.
Well given that kbuild-2.5 has a single makefile running out of $(TOPDIR), it _should_ be chopping the absolute pathname out of the include path and the .c path:
gcc -I include drivers/net/foo.c
There will be no starting-with-slash __FILE__s in the output of this command.
> It also sucks for inline functions or other users of BUG that would > potentially want to have different output. > > In short, I suspect it would be nicer with > > kernel BUG: release_task(current) > > instead of > > kernel BUG at /home/torvalds/v2.5/linux/exit.c:59 > > (the exact point where the BUG happens _is_ given by the EIP, so in that > sense file and linenr are not actually all that useful. A descriptive > string would be more readable, and equally useful at pinpointing at a > source level).
Isn't this the traditional assert(), which includes that-which-was-asserted in the message?
kernel assertion of "!PageLocked(page)" failed at foo.c:42.
That's easy to do in the context of BUG_ON(), and greatly increases our chances of pinpointing the failing line...
- - 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/
| |