trivial fix in linker script

There is a chance that __start___ksymtab may not point at the beginning of section __ksymtab. Appended/attached one line patch fixes this problem.

thanks,
suresh

diff -Nru linux-2.5.52/arch/ia64/vmlinux.lds.S~ linux-2.5.52/arch/ia64/vmlinux.lds.S
@@ -60,6 +60,7 @@
   machvec_end = .;
 #endif
 
+  . = ALIGN(16);
   __start___ksymtab = .;       /* Kernel symbol table */
   __ksymtab : AT(ADDR(__ksymtab) - PAGE_OFFSET)
        { *(__ksymtab) }

@@ -60,6 +60,7 @@
   machvec_end = .;
 #endif
 
+  . = ALIGN(16);
   __start___ksymtab = .;	/* Kernel symbol table */
   __ksymtab : AT(ADDR(__ksymtab) - PAGE_OFFSET)
 	{ *(__ksymtab) }

Suresh> There is a chance that __start___ksymtab may not point at Suresh> the beginning of section __ksymtab. Appended/attached one Suresh> line patch fixes this problem.

It seems to me that a better solution would be to move __start___ksymtab inside the __ksymtab section. That should make it always work, independent of what the real alignment of that section is.

	--david

hi David,

I agree. Attached a bigger patch now :)

thanks,
suresh

@@ -45,25 +45,29 @@
   _data = .;
 
   /* Exception table */
-  . = ALIGN(16);
-  __start___ex_table = .;
   __ex_table : AT(ADDR(__ex_table) - PAGE_OFFSET)
-	{ *(__ex_table) }
-  __stop___ex_table = .;
+	{ 
+	   __start___ex_table = .;
+	   *(__ex_table) 
+	   __stop___ex_table = .;
+	}
 
 #if defined(CONFIG_IA64_GENERIC)
   /* Machine Vector */
-  . = ALIGN(16);
-  machvec_start = .;
   .machvec : AT(ADDR(.machvec) - PAGE_OFFSET)
-	{ *(.machvec) }
-  machvec_end = .;
+	{ 
+  	   machvec_start = .;
+	   *(.machvec)
+	   machvec_end = .;
+	}
 #endif
 
-  __start___ksymtab = .;	/* Kernel symbol table */
   __ksymtab : AT(ADDR(__ksymtab) - PAGE_OFFSET)
-	{ *(__ksymtab) }
-  __stop___ksymtab = .;
+	{ 
+  	   __start___ksymtab = .;	/* Kernel symbol table */
+	   *(__ksymtab) 
+  	   __stop___ksymtab = .;
+	}
 
   __kallsyms : AT(ADDR(__kallsyms) - PAGE_OFFSET)
 	{

@@ -73,13 +77,14 @@
 	}
 
   /* Unwind info & table: */
-  . = ALIGN(8);
   .IA_64.unwind_info : AT(ADDR(.IA_64.unwind_info) - PAGE_OFFSET)
 	{ *(.IA_64.unwind_info*) }
-  ia64_unw_start = .;
   .IA_64.unwind : AT(ADDR(.IA_64.unwind) - PAGE_OFFSET)
-	{ *(.IA_64.unwind*) }
-  ia64_unw_end = .;
+	{ 
+	   ia64_unw_start = .;
+	   *(.IA_64.unwind*)
+	   ia64_unw_end = .;
+	}
 
   .rodata : AT(ADDR(.rodata) - PAGE_OFFSET)
 	{ *(.rodata) *(.rodata.*) }

@@ -98,23 +103,28 @@
   .init.data : AT(ADDR(.init.data) - PAGE_OFFSET)
 	{ *(.init.data) }
 
-  __initramfs_start = .;
   .init.ramfs : AT(ADDR(.init.ramfs) - PAGE_OFFSET)
-	{ *(.init.ramfs) }
-  __initramfs_end = .;
+	{ 
+  	   __initramfs_start = .;
+	   *(.init.ramfs)
+	   __initramfs_end = .;
+	}
 
-   . = ALIGN(16);
-  __setup_start = .;
   .init.setup : AT(ADDR(.init.setup) - PAGE_OFFSET)
-        { *(.init.setup) }
-  __setup_end = .;
-  __start___param = .;
+	{ 
+	   __setup_start = .;
+	   *(.init.setup)
+	   __setup_end = .;
+	}
   __param : AT(ADDR(__param) - PAGE_OFFSET)
-        { *(__param) }
-  __stop___param = .;
-  __initcall_start = .;
+	{ 
+	   __start___param = .;
+	   *(__param)
+	   __stop___param = .;
+	}
   .initcall.init : AT(ADDR(.initcall.init) - PAGE_OFFSET)
 	{
+		__initcall_start = .;
 		*(.initcall1.init)
 		*(.initcall2.init)
 		*(.initcall3.init)

@@ -122,8 +132,8 @@
 		*(.initcall5.init)
 		*(.initcall6.init)
 		*(.initcall7.init)
+		__initcall_end = .;
 	}
-  __initcall_end = .;
   . = ALIGN(PAGE_SIZE);
   __init_end = .;
 

@@ -138,7 +148,6 @@
 	  __stop_gate_section = .;
 	}
 
-  . = ALIGN(SMP_CACHE_BYTES);
   .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - PAGE_OFFSET)
         { *(.data.cacheline_aligned) }
 

Suresh> hi David, I agree. Attached a bigger patch now :)

Well, it's not pretty so I deferred working on it to the last, and then I got distracted and forgot to do something about it.

Where exactly does the problem come from? Is it that the Intel linker will complain when it finds the same symbol with different types? This kind of overzealous checking is quite a pain and is, IMHO, pretty much a bug (there are other annoying "features" like that in the Intel toolchain, for example that the assembler insists on all external symbols being declared; what a pain...). If we need to have a workaround, we can add one but we should clearly document why the ugly hacks are needed.

	--david

I would prefer to use the RODATA stuff that is included in 2.5.59. The error you correct, by including the symbol definition inside the section will appear as soon as Linus is back.
Andrew Morton has one version by H.J. Lu IIRC.
Kai has the same fix pending in his bitkeeper tree.

One day I will move more common stuff to include/asm-generic/vmlinux.lds.h

Sam

hi David,

I think you are mentioning about ret_from_clone patch here.

I am using GNU linker.

Inline with your observation, Intel compiler emits the type of extern variables. And now based on the order in which object files are linked, linker is failing in some cases.

If the object file with extern declaration comes after the object file with correct declaration, linker is working fine. But if the object file with extern declaration comes first, then linker is reporting "type of symbol changed" in the second object file with correct declaration.

gcc doesn't fix the type for extern variables, leaves it to the linker. So linking works irrespective of the order.

Is this a GNU linker issue?

thanks,
suresh

Suresh> I am using GNU linker.

I see.

Suresh> Inline with your observation, Intel compiler emits the type Suresh> of extern variables. And now based on the order in which Suresh> object files are linked, linker is failing in some cases.

Suresh> If the object file with extern declaration comes after the Suresh> object file with correct declaration, linker is working Suresh> fine. But if the object file with extern declaration comes Suresh> first, then linker is reporting "type of symbol changed" in Suresh> the second object file with correct declaration.

Huh, and this is a fatal error, not a warning?

Suresh> gcc doesn't fix the type for extern variables, leaves it to Suresh> the linker. So linking works irrespective of the order.

Suresh> Is this a GNU linker issue?

Perhaps. We might want to discuss it with Richard Henderson. Currently the GNU linker is a bit overzealous in enforcing certain restrictions anyhow, which make it a pain for the linux kernel (e.g., it doesn't allow the mixing of CONST_GP and non-CONST_GP files, even if the non-CONST_GP files contain only data, etc.). Perhaps it's just time to clean up the toolchain in this regard.

Don't get me wrong: I can live with the linker script magic if the toolchain folks argue that it is the proper way to handle this. I just want to avoid uglifying the kernel for no good reason.

	--david