lkml.org 
[lkml]   [2002]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:22    [W:0.027 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site