Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.48-00

[Paulo Marques]

Keith Owens wrote:
> On Wed, 08 Jun 2005 17:04:23 +0200, 
> Michal Schmidt <xschmi00@xxxxxxxxxxxxxxxxxx> wrote:
> > Paulo Marques wrote:
> >
> > > [...]
> > > and disable CONFIG_KALLSYMS_EXTRA_PASS, to see if the problem goes away?
> >
> > Yes, this helps.
> >
> > > It it does go away, then it is the same problem, and I'm working on it...
>
> Not the same problem.  The significant difference in the maps is :-
>
> --- .tmp_map1   2005-06-09 01:14:50.303658655 +1000
> +++ .tmp_map2   2005-06-09 01:14:52.829274854 +1000
> @@ -8326,8 +8326,8 @@
>  c02b93b0 T ipv6_skip_exthdr
>  c02b9500 T sha_transform
>  c02b96e0 T sha_init
> -c02b970f T __sched_text_start
>  c02b9710 t __compat_down
> +c02b9710 T __sched_text_start
>  c02b9810 t __compat_down_interruptible
>  c02b9948 T __compat_down_failed
>  c02b9958 T __compat_down_failed_interruptible
>
> __sched_text_start has moved up by 1 byte between pass 1 and 2.  Text
> addresses are not allowed to move between kallsyms passes, kallsyms
> only adds data, it never touches the text segment.  Paulo's change to
> the working set hides this peculiarity, rather than fixing the real
> cause.  This looks like a toolchain bug, it is moving symbols for no
> good reason.

Actually this is exactly the same problem we've seen in other threads: 
the symbol that marks the beggining of a section gets aligned to a 
different boundary on the second pass. Because it has now the same 
address as the next symbol, it gets sorted in reverse order.

I agree that this is the toolchain's fault, but I think kallsyms could 
be a little more robust and handle this without preventing the kernel 
from building properly.

--
Paulo Marques - www.grupopie.com

An expert is a person who has made all the mistakes that can be
made in a very narrow field.
Niels Bohr (1885 - 1962)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/