Re: silly [< >] and other excess

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Russell King writes:
> Andries.Brouwer@cwi.nl writes:

>> Of course. But since there is no information in [< >]
>> (their presence is syntactically determined, not semantically)
>> the tools you mention can be trivially patched to work without
>> this [< >] kludge. On the other hand, when the system panics
>> often klogd and similar nice programs do not run at all, and
>> hence are unable to do any good. All information available
>> is the information on the screen, and it is really a pity
>> to lose EIP and get a few parentheses instead.
>
> Well, in my experience, values of PC (or EIP is x86 speak) rarely
> appear over column 50 on the screen.  Therefore, removing them is
> only going to save width, not height.

Lots of useful data goes over column 80, causing even the innocent
little lines to scroll.

> Also, have you considered that not every oops is formatted exactly
> the same way on every architecture?  In fact, an oops on ARM looks
> like:

Hey, no problem.

> Unable to handle kernel NULL pointer dereference at virtual address 00000000

That 00000000 is an 8-digit hex number within 25 lines of things
that would suggest a problem, so it gets looked up. The text itself
counts as a hint too. ("kernel NULL pointer")

> pgd = c1e90000

Same thing. The "pgd" counts as a hint.

> *pgd = 01e94001, *pmd = 01e94001, *pte = 0000308b, *ppte = 0000300a

All 4 get looked up. Sure, they might not be symbols, but it is
better to err on the side of looking up extra junk.

> Internal error: Oops: 0

The "0" is only 1 digit, so don't look it up. The "Oops" is an
obvious hint to the userspace tool.

> CPU: 0
> pc : [<c280007c>]    lr : [<c00251f8>]
> sp : c1e97f08  ip : c1e97ec0  fp : c1e97f14
> r10: c1e96000  r9 : 00000004  r8 : ffffffea
> r7 : 02029220  r6 : c1e37000  r5 : c2800000  r4 : 00000000
> r3 : ef9f0000  r2 : 00000000  r1 : 00000000  r0 : 000001db

Gee, obvious register names and plenty of 8-digit hex numbers.

> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 1E9117D  Table: 01E9117D  DAC: 00000015
> Process insmod (pid: 9, stackpage=c1e97000)

When you see "stackpage", you have a hint.

> Stack:

Oh look, another hint.

> c1e97ee0:                                                        c00251f8 c280007c
> c1e97f00: 60000013 ffffffff c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000

[ --- CHOP --- ]

All these numbers get looked up.

> Backtrace:

That is another hint.

> Function entered at [<c2800060>] from [<c0026194>]
> Function entered at [<c0025ac0>] from [<c0016860>]
> Code: e51f2024 e5923000 (e5813000) e3a00000 e51f3030

All those numbers get looked up. Keep going for another 25 lines too.

> where each number in [< >] should be looked up in System.map.  Do you
> propose to teach klogd and ksymoops every single oops format style?

That isn't needed. When in doubt, look up a hex address.
Of course any decent tool will retain the unmolested oops
and just add a list of symbol names afterward.
-
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/