[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hfxbmpx7h.wl%tiwai@suse.de>
Date: Thu, 20 Aug 2009 12:59:46 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Hannes Reinecke <hare@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Jeremy Fitzhardinge <jeremy@...p.org>, stable@...nel.org
Subject: Re: [REGRESSION] _end symbol missing from Symbol.map
At Thu, 20 Aug 2009 07:59:26 +0200,
Hannes Reinecke wrote:
>
> Andrew Morton wrote:
> > On Thu, 13 Aug 2009 08:45:20 +0200 Hannes Reinecke <hare@...e.de> wrote:
> >
> >> Hi all,
> >>
> >> with 2.6.31 'crash' on x86_64 falls flat on its face as the '_end' symbol
> >> is missing from the System.map file.
> >>
> >> The culprit is commit 091e52c3551d3031343df24b573b770b4c6c72b6,
> >> which moved the '_end' symbol into it's own section.
> >> Apparently this causes kallsyms to not reference it properly.
> >>
> >> So either we'd need to revert part of the patch to not
> >> include _end in it's own section:
> >>
> >> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> >> index 59f31d2..1422df5 100644
> >> --- a/arch/x86/kernel/vmlinux.lds.S
> >> +++ b/arch/x86/kernel/vmlinux.lds.S
> >> @@ -376,9 +376,7 @@ SECTIONS
> >> __brk_limit = .;
> >> }
> >>
> >> - .end : AT(ADDR(.end) - LOAD_OFFSET) {
> >> - _end = .;
> >> - }
> >> + _end = .;
> >>
> >> /* Sections to be discarded */
> >> /DISCARD/ : {
> >>
> >> or someone has to fixup kallsyms. But this is far beyond my comfort zone.
> >>
> >
> > So System.map is part of the kernel API too? Sigh.
> >
> > Your email client replaces tabs with spaces.
> >
> I know.
>
> > The patch didn't have a signed-off-by:
> >
> I know, too.
> However, this is clearly a band-aid, and as such I reported
> it more as an RFC.
> One (Sam?) should really fix up kallsyms to extract the _end symbol.
> Hence I didn't warrant it with a Signed-off line.
>
> > I queued it up, and tagged it for -stable backporting. Unless we come
> > up with something better.
> >
> I was sort of hoping Sam would speak up and present some better approach ...
>
> > We might not get this into 2.6.31, in which case this fix or its
> > replacement will need backporting to 2.6.30.x and 2.6.31.x (IMO).
Yep, x86-32 had already the own end section in 2.6.30 kernel, which
was introduced by the following commit:
commit 0a699af8e613a670be50245366fa18cb19ac5172
Author: H. Peter Anvin <hpa@...ux.intel.com>
Date: Tue Mar 17 14:14:31 2009 -0700
x86-32: move _end to a dummy section
Impact: build fix with CONFIG_RELOCATABLE
Move _end into a dummy section, so that relocs.c will know it is a
relocatable symbol.
Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>
So, judging from the commit log, simply reverting it seems to have
some drawback...?
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists