From: Paulo Marques <pmarques@grupopie.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: inconsistent kallsyms data [2.6.11-mm2]
Date: Mon, 14 Mar 2005 13:33:47 +0000 [thread overview]
Message-ID: <423592BB.80207@grupopie.com> (raw)
In-Reply-To: <20050313085441.GA24006@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Thu, Mar 10, 2005 at 12:12:22PM +0000, Paulo Marques wrote:
>
>>Paulo Marques wrote:
>>
>>>[...]
>>>A simple and robust way is to do the sampling on a list of symbols
>>>sorted by symbol name. This way, even if the symbol positions that are
>>>given to scripts/kallsyms change, the symbols sampled will be the same.
>>>
>>>I'll do the patch to do this and send it ASAP.
>>
>>Ok, here it is.
>>
>>Dominik can you try the attached patch and see if it solves the problem?
>
> Hi Paulo.
Hi Sam :)
> Alexander Stohr had similar problems with down and __sched_text_start.
>
> I figured out that what was causing the troubles was the fact that the
> linker generated symbol __sched_text_start changed value from pass 1 to
> pass 2. The reason for this was the alingment used within that section.
Damn, you're right. Looking more carefully at Dominik's files I can see
that on the first pass we have:
T __sched_text_start PTR 0xc0420482
t __down PTR 0xc0420484
and on the second pass:
t __down PTR 0xc0420484
T __sched_text_start PTR 0xc0420484
I only looked at the addresses on the second pass and noticed they were
aliased symbols and that the symbol order changed from the first pass :P
> I never came around submitting this since I do not know what the correct
> number for function alignment is on different paltforms.
If this will just align the beginning of a section, I don't think it
will be a problem to always align at 8 bytes even on platforms that need
only a 4 byte alignment.
So I think that your patch should definitely go in, as it solves a real
problem.
As for my patch it could potentially solve problems that we don't
currently have(*), so it is probably better to wait for them to appear
before trying to solve an non-existent problem :)
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
(*) order of aliased symbols changing, or 'nm' returning non sorted
addresses.
next prev parent reply other threads:[~2005-03-14 13:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-08 11:38 2.6.11-mm2 Andrew Morton
2005-03-08 13:58 ` 2.6.11-mm2 Paul Mundt
2005-03-08 19:40 ` 2.6.11-mm2 Andrew Morton
2005-03-08 16:00 ` 2.6.11-mm2 (compile stats) John Cherry
2005-03-08 18:54 ` 2.6.11-mm2 fremap.c compile error Jurriaan
2005-03-11 22:50 ` Adrian Bunk
2005-03-08 19:29 ` inconsistent kallsyms data [2.6.11-mm2] Dominik Brodowski
2005-03-08 20:35 ` Andrew Morton
2005-03-08 20:45 ` Dominik Brodowski
2005-03-09 12:57 ` Paulo Marques
2005-03-09 20:16 ` Paulo Marques
2005-03-10 12:12 ` Paulo Marques
2005-03-13 8:54 ` Sam Ravnborg
2005-03-14 13:33 ` Paulo Marques [this message]
2005-03-14 22:17 ` Dominik Brodowski
2005-03-14 22:14 ` Dominik Brodowski
2005-03-08 23:20 ` 2.6.11-mm2 Christoph Hellwig
2005-03-08 23:29 ` 2.6.11-mm2 Andrew Morton
2005-03-08 23:36 ` 2.6.11-mm2 J.A. Magallon
2005-03-08 23:44 ` 2.6.11-mm2 Robert Love
2005-03-08 23:51 ` 2.6.11-mm2 J.A. Magallon
2005-03-09 0:02 ` 2.6.11-mm2 Robert Love
2005-03-09 0:16 ` 2.6.11-mm2 Adrian Bunk
2005-03-09 0:53 ` 2.6.11-mm2 Andrew Morton
2005-03-09 1:39 ` 2.6.11-mm2 Jeff Garzik
2005-03-09 0:20 ` 2.6.11-mm2 Adrian Bunk
2005-03-09 1:50 ` 2.6.11-mm2 Karsten Keil
2005-03-10 7:57 ` 2.6.11-mm2 Stefano Rivoir
[not found] ` <422FFDEF.2060706-g1Oybe70Lz0@public.gmane.org>
2005-03-10 8:09 ` 2.6.11-mm2 Andrew Morton
2005-03-10 8:09 ` 2.6.11-mm2 Andrew Morton
2005-05-25 22:43 ` 2.6.11-mm2 Andrew Morton
[not found] ` <20050525154308.57cde7ab.akpm-3NddpPZAyC0@public.gmane.org>
2005-05-26 17:43 ` 2.6.11-mm2 Stefano Rivoir
2005-03-21 23:45 ` 2.6.11-mm2 Andrew Morton
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=423592BB.80207@grupopie.com \
--to=pmarques@grupopie.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=sam@ravnborg.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.