Fix .altinstructions linking failures
diff mbox series

Message ID 20030506063055.GA15424@averell
State New, archived
Headers show
Series
  • Fix .altinstructions linking failures
Related show

Commit Message

Andi Kleen May 6, 2003, 6:30 a.m. UTC
Some configs didn't link anymore because they got references from
.altinstructions to __exit functions. Fixing it at the linker level
is not easily possible. This patch just discards .text.exit at runtime
instead of link time to avoid this.

Idea from Andrew Morton.

It will also fix a related problem with .eh_frame in modern gcc (so far 
only observed on x86-64, but could happen on i386 too) 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Comments

Adrian Bunk May 6, 2003, 4:44 p.m. UTC | #1
On Tue, May 06, 2003 at 08:30:55AM +0200, Andi Kleen wrote:
> 
> Some configs didn't link anymore because they got references from
> .altinstructions to __exit functions. Fixing it at the linker level
> is not easily possible. This patch just discards .text.exit at runtime
> instead of link time to avoid this.
> 
> Idea from Andrew Morton.
> 
> It will also fix a related problem with .eh_frame in modern gcc (so far 
> only observed on x86-64, but could happen on i386 too) 
> 
> Index: linux/arch/i386/vmlinux.lds.S
> ===================================================================
> RCS file: /home/cvs/linux-2.5/arch/i386/vmlinux.lds.S,v
> retrieving revision 1.18
> diff -u -u -r1.18 vmlinux.lds.S
> --- linux/arch/i386/vmlinux.lds.S	30 Apr 2003 14:32:05 -0000	1.18
> +++ linux/arch/i386/vmlinux.lds.S	6 May 2003 05:28:28 -0000
> @@ -85,7 +85,10 @@
>    __alt_instructions = .;
>    .altinstructions : { *(.altinstructions) } 
>    __alt_instructions_end = .; 
> - .altinstr_replacement : { *(.altinstr_replacement) }
> + .altinstr_replacement : { *(.altinstr_replacement) } 
> +  /* .exit.text is discard at runtime, not link time, to deal with references
> +     from .altinstructions and .eh_frame */
> +  .exit.text : { *(.exit.text) }
>    . = ALIGN(4096);
>    __initramfs_start = .;
>    .init.ramfs : { *(.init.ramfs) }
> @@ -106,7 +109,6 @@
>  
>    /* Sections to be discarded */
>    /DISCARD/ : {
> -	*(.exit.text)
>  	*(.exit.data)
>  	*(.exitcall.exit)
>  	}
> 

This patch is bogus.

The result are tons of
  undefined reference to `local symbols in discarded section .exit.data'

This problem might be solved by moving the .exit.data, too.

The next thing that breaks are things like the following:
drivers/built-in.o(.exit.text+0x4c25): In function `cpia_exit':
: undefined reference to `proc_cpia_destroy'

The problem is in drivers/media/video/cpia.c:

<--  snip  -->

...
#ifdef MODULE
static void proc_cpia_destroy(void)
{
        remove_proc_entry("cpia", 0);
}
#endif /*MODULE*/
...
static void __exit cpia_exit(void)
{
#ifdef CONFIG_PROC_FS
        proc_cpia_destroy();
#endif
}
...

<--  snip  -->



Please fix all of the problems your changes in 2.5.69 created.


TIA
Adrian
Andi Kleen May 6, 2003, 7:56 p.m. UTC | #2
On Tue, May 06, 2003 at 06:44:41PM +0200, Adrian Bunk wrote:
> <--  snip  -->
> 
> ...
> #ifdef MODULE
> static void proc_cpia_destroy(void)
> {
>         remove_proc_entry("cpia", 0);
> }
> #endif /*MODULE*/
> ...
> static void __exit cpia_exit(void)
> {
> #ifdef CONFIG_PROC_FS
>         proc_cpia_destroy();
> #endif
> }

The driver is buggy. The #ifdef MODULE needs to be removed and proc_cpia_destroy 
be marked __exit instead, then things will be ok.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andi Kleen May 6, 2003, 9:08 p.m. UTC | #3
On Tue, May 06, 2003 at 09:56:14PM +0200, Andi Kleen wrote:
> The driver is buggy. The #ifdef MODULE needs to be removed and proc_cpia_destroy 
> be marked __exit instead, then things will be ok.

FWIW I compiled a "maxi kernel" now (with everything that compiles compiled in) 
and only cpia seems to have this bug. So with this patch things should be ok
again.

-Andi

Index: linux/drivers/media/video/cpia.c
===================================================================
RCS file: /home/cvs/linux-2.5/drivers/media/video/cpia.c,v
retrieving revision 1.25
diff -u -u -r1.25 cpia.c
--- linux/drivers/media/video/cpia.c	25 Apr 2003 05:41:01 -0000	1.25
+++ linux/drivers/media/video/cpia.c	6 May 2003 20:08:34 -0000
@@ -1409,12 +1409,10 @@
 		LOG("Unable to initialise /proc/cpia\n");
 }
 
-#ifdef MODULE
-static void proc_cpia_destroy(void)
+static void __exit proc_cpia_destroy(void)
 {
 	remove_proc_entry("cpia", 0);
 }
-#endif /*MODULE*/
 #endif /* CONFIG_PROC_FS */
 
 /* ----------------------- debug functions ---------------------- */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andrew Morton May 6, 2003, 9:25 p.m. UTC | #4
Andi Kleen <ak@muc.de> wrote:
>
> On Tue, May 06, 2003 at 09:56:14PM +0200, Andi Kleen wrote:
> > The driver is buggy. The #ifdef MODULE needs to be removed and proc_cpia_destroy 
> > be marked __exit instead, then things will be ok.
> 
> FWIW I compiled a "maxi kernel" now (with everything that compiles compiled in) 
> and only cpia seems to have this bug. So with this patch things should be ok
> again.

Where should we be discarding .exit.data?  link-time or runtime?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andi Kleen May 6, 2003, 9:45 p.m. UTC | #5
On Tue, May 06, 2003 at 11:25:51PM +0200, Andrew Morton wrote:
> Andi Kleen <ak@muc.de> wrote:
> >
> > On Tue, May 06, 2003 at 09:56:14PM +0200, Andi Kleen wrote:
> > > The driver is buggy. The #ifdef MODULE needs to be removed and proc_cpia_destroy 
> > > be marked __exit instead, then things will be ok.
> > 
> > FWIW I compiled a "maxi kernel" now (with everything that compiles compiled in) 
> > and only cpia seems to have this bug. So with this patch things should be ok
> > again.
> 
> Where should we be discarding .exit.data?  link-time or runtime?

Run time is probably safer.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jörn Engel May 7, 2003, 9:23 a.m. UTC | #6
On Tue, 6 May 2003 08:30:55 +0200, Andi Kleen wrote:
> 
> Some configs didn't link anymore because they got references from
> .altinstructions to __exit functions. Fixing it at the linker level
> is not easily possible. This patch just discards .text.exit at runtime
> instead of link time to avoid this.
> 
> Idea from Andrew Morton.
> 
> It will also fix a related problem with .eh_frame in modern gcc (so far 
> only observed on x86-64, but could happen on i386 too) 

But it sure won't make any embedded people happy. This adds .text.exit
(and .data.exit?) to the kernel image, which is nothing but
unnecessary bloat. Nothing inside those sections is ever used, yet
their footprint does hurt on small systems.

I've been a bit sceptical of the whole .altinstructions idea,
self-modifying code opens a can of worms for anyone trying to do code
analysis (coverage, verification,...). But with this followup, I
personally pay money to get that stuff ripped out again.

Jörn
Andi Kleen May 7, 2003, 9:47 a.m. UTC | #7
[cc list trimmed]

On Wed, May 07, 2003 at 11:23:29AM +0200, Jörn Engel wrote:
> I've been a bit sceptical of the whole .altinstructions idea,
> self-modifying code opens a can of worms for anyone trying to do code
> analysis (coverage, verification,...). But with this followup, I
> personally pay money to get that stuff ripped out again.

Ok. How much do you pay ? ;@)

Seriously. To give some numbers. This is the maxi kernel (about 8MB .text,
everything compiled in that compiles in 2.5.69) which is far too big to even 
even boot.

 20 .exit.text    00005afa  c0ada3d0  c0ada3d0  009db3d0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

About 20k from 8MB

On a realistic kernel that actually boots we are talking about 1-2KB,
probably even less. If you really wanted to combat bloat there are a lot 
other areas where you can avoid much more than 2KB with minimum effort.
Just go through include/linux/* and move a few unnecessary inlines away, that
will help much more. If you want to save real memory attack mem_map, like
I proposed earlier.

-Andi

P.S.: In case someone is interested: The hall of shame for the 2.5.69 SMP
maxi kernel (stuff that doesn't build) currently is:  Sound/Alsa (one driver 
doesn't compile), USB (3 drivers don't compile), MTD (lots of stuff doesn't 
compile).  Everything else is quite good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jörn Engel May 7, 2003, 10:16 a.m. UTC | #8
On Wed, 7 May 2003 11:47:52 +0200, Andi Kleen wrote:
> Seriously. To give some numbers. This is the maxi kernel (about 8MB .text,
> everything compiled in that compiles in 2.5.69) which is far too big to even 
> even boot.
> 
>  20 .exit.text    00005afa  c0ada3d0  c0ada3d0  009db3d0  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> About 20k from 8MB
>
> On a realistic kernel that actually boots we are talking about 1-2KB,
> probably even less.

Sounds more like 1/2 maxi to me, but you are basically right. 2-3k on
one of my production embedded kernels. I can accept that, but it
doesn't really make me happy.

> If you really wanted to combat bloat there are a lot 
> other areas where you can avoid much more than 2KB with minimum effort.
> Just go through include/linux/* and move a few unnecessary inlines away, that
> will help much more. If you want to save real memory attack mem_map, like
> I proposed earlier.

Still on my list, but I didn't get to it yet.

> P.S.: In case someone is interested: The hall of shame for the 2.5.69 SMP
> maxi kernel (stuff that doesn't build) currently is:  Sound/Alsa (one driver 
> doesn't compile), USB (3 drivers don't compile), MTD (lots of stuff doesn't 
> compile).  Everything else is quite good.

Do you have a .config for that kernel. I tried to create a maximal one
for 2.5.69 as well, but the problems in the Subject: stopped me and ld
didn't give me enough clues, which drivers to remove.

Jörn
Greg KH May 7, 2003, 4:38 p.m. UTC | #9
On Wed, May 07, 2003 at 11:47:52AM +0200, Andi Kleen wrote:
> USB (3 drivers don't compile)

What 3 USB drivers do not compile in the current tree?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Adrian Bunk May 10, 2003, 8:50 a.m. UTC | #10
On Wed, May 07, 2003 at 11:47:52AM +0200, Andi Kleen wrote:
>...
> P.S.: In case someone is interested: The hall of shame for the 2.5.69 SMP
> maxi kernel (stuff that doesn't build) currently is:  Sound/Alsa (one driver 
> doesn't compile), USB (3 drivers don't compile), MTD (lots of stuff doesn't 
> compile).  Everything else is quite good.

At about a dozen SCSI drivers plus half a dozen drivers under 
drivers/char/* don't compile in 2.5.69 even for non-SMP. How did you 
manage to compile these?

cu
Adrian
Jörn Engel May 10, 2003, 3:41 p.m. UTC | #11
On Sat, 10 May 2003 10:50:22 +0200, Adrian Bunk wrote:
> On Wed, May 07, 2003 at 11:47:52AM +0200, Andi Kleen wrote:
> > P.S.: In case someone is interested: The hall of shame for the 2.5.69 SMP
> > maxi kernel (stuff that doesn't build) currently is:  Sound/Alsa (one driver 
> > doesn't compile), USB (3 drivers don't compile), MTD (lots of stuff doesn't 
> > compile).  Everything else is quite good.
> 
> At about a dozen SCSI drivers plus half a dozen drivers under 
> drivers/char/* don't compile in 2.5.69 even for non-SMP. How did you 
> manage to compile these?

Just so we can name those drivers, this is the diff between my maximal
config for 2.5.69 and allyesconfig. Well, for easier reading, it is
piped through grep '^-'.

Is this list of any interest? Should I generate it regularly for newer
kernels? Would anyone actually read it and fix things?

Jörn

Patch
diff mbox series

Index: linux/arch/i386/vmlinux.lds.S
===================================================================
RCS file: /home/cvs/linux-2.5/arch/i386/vmlinux.lds.S,v
retrieving revision 1.18
diff -u -u -r1.18 vmlinux.lds.S
--- linux/arch/i386/vmlinux.lds.S	30 Apr 2003 14:32:05 -0000	1.18
+++ linux/arch/i386/vmlinux.lds.S	6 May 2003 05:28:28 -0000
@@ -85,7 +85,10 @@ 
   __alt_instructions = .;
   .altinstructions : { *(.altinstructions) } 
   __alt_instructions_end = .; 
- .altinstr_replacement : { *(.altinstr_replacement) }
+ .altinstr_replacement : { *(.altinstr_replacement) } 
+  /* .exit.text is discard at runtime, not link time, to deal with references
+     from .altinstructions and .eh_frame */
+  .exit.text : { *(.exit.text) }
   . = ALIGN(4096);
   __initramfs_start = .;
   .init.ramfs : { *(.init.ramfs) }
@@ -106,7 +109,6 @@ 
 
   /* Sections to be discarded */
   /DISCARD/ : {
-	*(.exit.text)
 	*(.exit.data)
 	*(.exitcall.exit)
 	}