From: Keith Owens <kaos@ocs.com.au>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Akinobu Mita <mita@miraclelinux.com>,
ak@suse.de, linux-kernel@vger.kernel.org,
Chuck Ebbert <76306.1226@compuserve.com>,
Christoph Hellwig <hch@infradead.org>,
Jesper Juhl <jesper.juhl@gmail.com>
Subject: Re: [PATCH 0/4] compact call trace
Date: Tue, 17 Jan 2006 21:42:52 +1100 [thread overview]
Message-ID: <10265.1137494572@ocs3.ocs.com.au> (raw)
In-Reply-To: Your message of "Tue, 17 Jan 2006 11:31:27 BST." <1137493887.3005.21.camel@laptopd505.fenrus.org>
Arjan van de Ven (on Tue, 17 Jan 2006 11:31:27 +0100) wrote:
>On Tue, 2006-01-17 at 19:13 +0900, Akinobu Mita wrote:
>> These patches will:
>>
>> - break the various custom oops-parsers which people have written themselves.
>> - use common call trace format on x86-64.
>> - change offset format from hexadecimal to decimal in print_symbol()
>> - delete symbolsize in call trace in print_symbol().
>> - print system_utsname.version in oops so that we can doing a
>> double check that the oops is matching the vmlinux we're looking at.
>
>
>at least then make the kallsyms lookup mark up the string somehow (say
>by putting a * in front of it) if the EIP is outside the size of the
>symbol; so that we can spot garbage better.
There is no such thing as "outside the size of the symbol". kallsyms
does not save symbol size, it is calculated as the difference between
this symbol and the next one in the table. By definition, every size
is correct - as long as all symbols are in the table.
Some symbols are omitted from kallsyms, which makes the calculation of
"symbol size" wrong for some symbols, those symbols appear bigger than
they really are. Printing the symbol size was done years ago as a hint
to the reader, it told them what the kernel thought the symbol size was
and gave them something to check against. That was when there were
very few symbols in the kernel, so most size calculations were wrong.
Nowadays it is probably irrelevant.
prev parent reply other threads:[~2006-01-17 10:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-17 10:13 [PATCH 0/4] compact call trace Akinobu Mita
2006-01-17 10:14 ` [PATCH 1/4] makes print_symbol() return int Akinobu Mita
2006-01-17 10:15 ` [PATCH 2/4] x86-64: Use print_symbol() to dump call trace Akinobu Mita
2006-01-17 10:15 ` [PATCH 3/4] compact print_symbol() output Akinobu Mita
2006-01-17 10:34 ` Keith Owens
2006-01-17 10:52 ` Jesper Juhl
2006-01-17 10:58 ` Akinobu Mita
2006-01-17 11:01 ` Keith Owens
2006-01-17 11:23 ` Akinobu Mita
2006-01-17 15:01 ` Hugh Dickins
2006-01-17 15:01 ` Andi Kleen
2006-01-17 10:16 ` [PATCH 4/4] i386: print system_utsname.version in oops Akinobu Mita
2006-01-17 10:31 ` [PATCH 0/4] compact call trace Arjan van de Ven
2006-01-17 10:42 ` Keith Owens [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10265.1137494572@ocs3.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=76306.1226@compuserve.com \
--cc=ak@suse.de \
--cc=arjan@infradead.org \
--cc=hch@infradead.org \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mita@miraclelinux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox