[Linux-ia64] [Patch] trivial fix in linker script

[Linux-ia64] [Patch] trivial fix in linker script

[Siddha, Suresh B]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

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
--- linux-2.5.52/arch/ia64/vmlinux.lds.S~       Mon Jan 20 18:42:47 2003
+++ linux-2.5.52/arch/ia64/vmlinux.lds.S        Mon Jan 20 18:43:42 2003
@@ -60,6 +60,7 @@
   machvec_end = .;
 #endif
 
+  . = ALIGN(16);
   __start___ksymtab = .;       /* Kernel symbol table */
   __ksymtab : AT(ADDR(__ksymtab) - PAGE_OFFSET)
        { *(__ksymtab) }


[-- Attachment #2: vmlinux.lds.S.diff --]
[-- Type: application/octet-stream, Size: 329 bytes --]

--- linux-2.5.52/arch/ia64/vmlinux.lds.S~	Mon Jan 20 18:42:47 2003
+++ linux-2.5.52/arch/ia64/vmlinux.lds.S	Mon Jan 20 18:43:42 2003
@@ -60,6 +60,7 @@
   machvec_end = .;
 #endif
 
+  . = ALIGN(16);
   __start___ksymtab = .;	/* Kernel symbol table */
   __ksymtab : AT(ADDR(__ksymtab) - PAGE_OFFSET)
 	{ *(__ksymtab) }

Re: [Linux-ia64] [Patch] trivial fix in linker script

[David Mosberger]

>>>>> On Mon, 20 Jan 2003 19:16:09 -0800, "Siddha, Suresh B" <suresh.b.siddha@intel.com> said:

  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

RE: [Linux-ia64] [Patch] trivial fix in linker script

[Siddha, Suresh B]

[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]

hi David,

I agree. Attached a bigger patch now :)

thanks,
suresh

--- linux-2.5.52/arch/ia64/vmlinux.lds.S~	Fri Jan 17 17:58:44 2003
+++ linux-2.5.52/arch/ia64/vmlinux.lds.S	Fri Jan 24 11:08:06 2003
@@ -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) }
 

> -----Original Message-----
> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Friday, January 24, 2003 10:30 AM
> To: Siddha, Suresh B
> Cc: davidm@hpl.hp.com; linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] [Patch] trivial fix in linker script
> 
> 
> >>>>> On Mon, 20 Jan 2003 19:16:09 -0800, "Siddha, Suresh B" 
> <suresh.b.siddha@intel.com> said:
> 
>   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
> 

[-- Attachment #2: vmlinux.lds.S.diff --]
[-- Type: application/octet-stream, Size: 2857 bytes --]

--- linux-2.5.52/arch/ia64/vmlinux.lds.S~	Fri Jan 17 17:58:44 2003
+++ linux-2.5.52/arch/ia64/vmlinux.lds.S	Fri Jan 24 11:08:06 2003
@@ -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) }
 

RE: [Linux-ia64] [Patch] trivial fix in linker script

[David Mosberger]

>>>>> On Fri, 24 Jan 2003 12:05:35 -0800, "Siddha, Suresh B" <suresh.b.siddha@intel.com> said:

  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

Re: [Linux-ia64] [Patch] trivial fix in linker script

[Sam Ravnborg]

On Fri, Jan 24, 2003 at 12:05:35PM -0800, Siddha, Suresh B wrote:
> hi David,
> 
> I agree. Attached a bigger patch now :)

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

RE: [Linux-ia64] [Patch] trivial fix in linker script

[Siddha, Suresh B]

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

> -----Original Message-----
> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Tuesday, January 28, 2003 11:15 AM
> To: Siddha, Suresh B
> Cc: linux-ia64@linuxia64.org
> Subject: RE: [Linux-ia64] [Patch] trivial fix in linker script
> 
> 
> >>>>> On Fri, 24 Jan 2003 12:05:35 -0800, "Siddha, Suresh B" 
> <suresh.b.siddha@intel.com> said:
> 
>   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
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] [Patch] trivial fix in linker script

[David Mosberger]

>>>>> On Wed, 29 Jan 2003 10:30:52 -0800, "Siddha, Suresh B" <suresh.b.siddha@intel.com> said:

  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