Re: [PATCH] x86-64: fix build with older binutils

[Sam Ravnborg]

Hi Jan.

On Wed, May 06, 2009 at 07:59:04AM +0100, Jan Beulich wrote:
> >>> Sam Ravnborg <sam@xxxxxxxxxxxx> 05.05.09 18:39 >>>
> >I like the way your patch simplies the linker scrip for x86.
> >We have recently merged the linker scripts for 32 and 64 bit,
> >and I tried to apply your patch on top of the unified version.
> >(Applied manually obviously).
> >
> >With a 64 bit defconfig build I got:
> >/home/sam/x-tools/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-ld: section .vsyscall_0 [00000000016c6000 -> >00000000016c60e7] overlaps section .init.rodata [00000000016c5a00 -> 00000000016c6348]
> >make[1]: *** [.tmp_vmlinux1] Error 1
> >
> >I did not try to build a kernel with your original patch.
> >
> >Can you spot anything obvious wrong in my patch.
> >It is on top of x86/kbuild in -tip.
> 
> Yeah, the placement of .init.start appears to be wrong - it should the
> SMP/x86-64 case of the per-CPU segment, and it should also be the
> one getting the :init attached. Hopefully that won't get us back to the
> binutils problem I was originally encountering - what is the extra .init.start
> section good for anyway?

.init.start is there so __init_begin is not an absolute symbol to support
a relocable kernel.
I named the section .init.stat because we have the

    PERCPU_VADDR(0, :percpu)

stuff inbetween this and .init.text



> And why does __init_end continue to live
> outside of any section (this sort of thing causes problems with
> CONFIG_RELOCATABLE and older binutils afair, as such symbols get
> marked absolute by the latter)?

Talking about this snippet where __init_end is inside
a .init.end output section.

        /* freed after init ends here */
        .init.end : AT(ADDR(.init.end) - LOAD_OFFSET) {
                __init_end = .;
        }

This was copied from 32 bit verbatim.

I would love to stick it inside one of the already defined sections.
But to minimize chrunch when we merged I kept the 32 bit layout.

> Btw., why is .data.nosave being placed differently for 32- and 64-bit?

A merge artifact - again to try to minimize changes - plus the fact that
on 64 we added it to a specific segment whereas we did not do so in 32 bit.

And I'm yet to fully understand the use of segments so I am reluctant
to touch it for now.

If you feel inclined it would be great if you could give the merged
linker script an overhaul. There is obviously stuff to be simplified and
I have limited time to do so atm.

	Sam
--
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/