Messages in this thread | | | Date | Sat, 11 May 2002 02:04:02 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] BUG() disassembly tweak |
| |
On Fri, 10 May 2002, Linus Torvalds wrote: > On Fri, 10 May 2002, Hugh Dickins wrote: > > > > Could we change the i386 BUG() macro slightly again? > > 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.
Aaargh, rerun! Last time I suggested a tiny mod to get BUG() working right (not losing the registers in its message display), you had new ideas of how it could work, saving kernel space; and Andrew implemented that magnificently.
I thought I was the only one dissatisfied (that a disassembler cannot make sense of this line number and filename pointer dumped into the instruction stream after the ud2: laugh at the ingenious instructions ksymoops shows after the ud2 these days).
> 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.
Absolute filenames are long, yes, but (in 2.4 anyway) few remain: the .c filenames never came out absolute, always just leafname, and Andrew has dealt with the vast majority of the .h filenames from inlines (e.g. by using out_of_line_bug for them). Does the 2.5 build not work out like that?
It's really 2.4.19 that's worrying me, that a small tweak now (exchanging line and file) can make the new style much more palatable to disassemblers; once 2.4.19 is out, it'll be confusing to change (disassemblers don't ususally need to know the version of what they are disassembling: no problem for kdb, but a problem for objdump).
> 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)
Sure there's a case for more info; but maybe that's something else than the simple BUG() we're used to dropping in wherever; let's fix up what we've got now, and muse at leisure on what else to provide.
> instead of > > kernel BUG at /home/torvalds/v2.5/linux/exit.c:59
I don't see those - exit.c:59 would be all you see in 2.4.19-pre. "strings vmlinux | grep /home" currently shows me just:
/home/hugh/1908H/include/linux/raid/md_k.h /home/hugh/1908H/include/linux/nfs_page.h /home/hugh/1908H/include/linux/nfs_page.h /home/hugh/1908H/include/linux/nfs_page.h /home/hugh/1908H/include/linux/nfs_page.h
> (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).
Hackers have better things to concentrate upon than dreaming up descriptive strings: the beauty of BUG() is that you can just drop it in (oops, I was about to say "without thinking"). I don't deny the case for assertions, but what Andrew provided last time around is really pretty good, and slips down more easily with the line<->file.
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/
| |