Russell King writes:
> Albert D. Cahalan writes:
>> Symbols:
>> c000000a __start
>> c0105344 qfs_frob_directory
>> c01a4600 qfs_cleaner
>> c01a4b98 qfs_hash_file_record
...
>> Well, that first symbol (__start) was really "jump +10", but the
>> extra noise doesn't hurt anyone. You get what you need, no matter
>> how mangled the oops is. It can be word-wrapped, missing chunks...
>> The tool doesn't need to care.
>
> However, now rather than just reading the dump as you can with
> ksymoops or whatever, you have to look at the raw data and try
> to match it up with a symbol in the list.
Yes. Don't you look at the raw data anyway?
Um, maybe you just don't work the way I do. In response to one
of your other messages, most of the time I have two PowerPC books
open on my desk. I hadn't thought that was so odd.
If you are going to rely on a tool, you might as well add some
error correction bits to the oops, base-32 encode it, and chop
it up into 5-character words for ease of paper-and-pencil copy.
> So, with that ARM dump I gave you, we'd potentially end up with
> about 100 lines of symbols, where about 90 of them are useless.
In theory yes, but in practice no. Your kernel isn't a significant
portion of your address space, so the chance of random data being
looked up successfully is very low. Maybe a 1% chance on 32-bit
hardware, and far less on 64-bit hardware.
> That would be a backwards step in the development of Linux IMHO.
>
> PS, you're not going to convince me unless you can come up with something
> that produces ksymoops-like output, so there's no point continuing.
Damn.
Somebody else posted a reasonable hack for the [<>] problem.
His proposal involved letting multiple values share the same
markers, something like this:
[<c19a5cb4 c180234c c1801134 c1706550 c1800248 c1603310 c1934878 c1840324>]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:13 EST