Re: gcc 4.1.1 issues with 2.6.17-rc5

["Randy.Dunlap" <rdunlap@xenotime.net>]

On Mon, 29 May 2006 14:52:25 +1000 Con Kolivas wrote:

> On Monday 29 May 2006 02:32, Atsushi Nemoto wrote:
> > On Sat, 27 May 2006 22:39:45 -0700, "Randy.Dunlap" <rdunlap@xenotime.net> 
> wrote:
> > > > and a missed one:
> > > > WARNING: drivers/usb/storage/usb-storage.o - Section mismatch:
> > > > reference to .exit.text: from .smp_locks after '' (at offset 0x40)
> > >
> > > Yep, Jesper posted that one.
> > > I also see it in ieee1394.o.
> > >
> > > So where does the .smp_locks section come from?
> > > Is this just a section checker bug/issue?
> >
> > The .smp_locks section comes from LOCK_PREFIX on x86.  I think the
> > warnings was not shown previously just because the modpost did not
> > check SHT_REL sections.
> >
> > Maybe we should fix the modpost to ignore it, but I'm not sure.  Is it
> > really safe to ignore?  I'm not a x86 expert ...
> 
> A "scary but harmless" comment from someone in the know would be nice.

Yes, I understand your remark.
I have looked at the twisty maze of alternatives code, but Gerd
(added to To:) is really who needs to reply IMO.

Based on my source code reading, it is just scary but harmless.
alternatives_smp_unlock() and alternatives_smp_lock() are passed
beginning and end addresses of text sections and they ignore
(init/exit) code addresses that are outside of the text code
range.
One comment says:
	/* .text segment, needed to avoid patching init code ;) */
and the code does appear to implement that.

I would make one small change to the code, however.
In alternatives_smp_lock() and alternatives_smp_unlock(), change

		if (*ptr > text_end)
			continue;
to
		if (*ptr >= text_end)
			continue;
because text_end is text_start + text_size, so text_end could be
the beginning of the next section.  However, in practice this
may not matter.

---
~Randy