Build error: `.exit.text' referenced in section `.rodata'

Build error: `.exit.text' referenced in section `.rodata'

[Thorsten Kranzkowski]

Hello,

compiling 2.6.26-rc1 (latest git) on an Alpha DS20 (ev6, everything built in,
gcc version 4.1.2) fails with the following link errors:

  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
`.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2


The problem also exists in 2.6.25 and probably several previous versions. 
I didn't try to determine where it started, though.


Trying to find the root of this problem I tried this:

bash-3.00$ objdump -r --section=.rodata /usr/src/linux-2.6.26-rc1-ds20/drivers/built-in.o  |grep exit.text
0000000000015558 GPREL32           .exit.text+0x0000000000001084
000000000001555c GPREL32           .exit.text+0x0000000000001060
0000000000015560 GPREL32           .exit.text+0x0000000000001060
0000000000015564 GPREL32           .exit.text+0x0000000000001060
0000000000015568 GPREL32           .exit.text+0x0000000000001060
000000000001556c GPREL32           .exit.text+0x0000000000001060
0000000000015570 GPREL32           .exit.text+0x0000000000001060
0000000000015574 GPREL32           .exit.text+0x0000000000001060
0000000000015578 GPREL32           .exit.text+0x0000000000001068
000000000001557c GPREL32           .exit.text+0x0000000000001068
0000000000015580 GPREL32           .exit.text+0x0000000000001068
0000000000015584 GPREL32           .exit.text+0x0000000000001068
0000000000015588 GPREL32           .exit.text+0x0000000000001068
000000000001558c GPREL32           .exit.text+0x0000000000001068
0000000000015590 GPREL32           .exit.text+0x0000000000001068
0000000000015594 GPREL32           .exit.text+0x0000000000001068


bash-3.00$ objdump -t --section=.exit.text /usr/src/linux-2.6.26-rc1-ds20/drivers/built-in.o  

...
0000000000000e8c l     F .exit.text     000000000000010c 0x88 exit_st
0000000000000f98 l     F .exit.text     000000000000012c 0x88 exit_sd
00000000000010c4 l     F .exit.text     0000000000000054 0x88 exit_sr
0000000000001118 l     F .exit.text     00000000000000e0 0x88 exit_sg
00000000000011f8 l     F .exit.text     0000000000000080 0x88 exit_ch_module
0000000000001278 l     F .exit.text     0000000000000050 0x88 ses_exit
...


--> ok looks like exit_sd is the culprit, which is contained in sd.c


bash-3.00$ objdump -r --section=.rodata /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o 

...
0000000000000054 GPREL32           .text+0x000000000000316c
0000000000000058 GPREL32           .exit.text+0x00000000000000ec
000000000000005c GPREL32           .exit.text+0x00000000000000c8
0000000000000060 GPREL32           .exit.text+0x00000000000000c8
0000000000000064 GPREL32           .exit.text+0x00000000000000c8
0000000000000068 GPREL32           .exit.text+0x00000000000000c8
000000000000006c GPREL32           .exit.text+0x00000000000000c8
0000000000000070 GPREL32           .exit.text+0x00000000000000c8
0000000000000074 GPREL32           .exit.text+0x00000000000000c8
0000000000000078 GPREL32           .exit.text+0x00000000000000d0
000000000000007c GPREL32           .exit.text+0x00000000000000d0
0000000000000080 GPREL32           .exit.text+0x00000000000000d0
0000000000000084 GPREL32           .exit.text+0x00000000000000d0
0000000000000088 GPREL32           .exit.text+0x00000000000000d0
000000000000008c GPREL32           .exit.text+0x00000000000000d0
0000000000000090 GPREL32           .exit.text+0x00000000000000d0
0000000000000094 GPREL32           .exit.text+0x00000000000000d0
0000000000000098 GPREL32           .init.text+0x00000000000000a8
...


--> ok, sd.c seems to be right, now where are these symbols actually used?


objdump -r  /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o

RELOCATION RECORDS FOR [.exit.text]:
OFFSET           TYPE              VALUE
...
00000000000000b0 GPRELHIGH         .rodata+0x0000000000000058
00000000000000b4 GPRELLOW          .rodata+0x0000000000000058
...


--> so they are used from inside .exit.text which contains only one function (in sd.o):

objdump --disassemble -S  --section=.exit.text /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o

...
  94:   00 00 ba 27     ldah    gp,0(ra)
  98:   00 00 bd 23     lda     gp,0(gp)
  9c:   10 04 ff 47     clr     a0
  a0:   01 00 5f 20     lda     t1,1
  a4:   22 f6 41 48     zapnot  t1,0xf,t1
  a8:   a1 f7 41 40     cmpule  t1,0xf,t0
  ac:   0a 00 20 e4     beq     t0,d8 <exit_sd+0xd8>
  b0:   00 00 3d 24     ldah    t0,0(gp)
  b4:   00 00 21 20     lda     t0,0(t0)
  b8:   41 04 41 40     s4addq  t1,t0,t0
  bc:   00 00 21 a0     ldl     t0,0(t0)
  c0:   01 04 a1 43     addq    gp,t0,t0
  c4:   02 00 e1 6b     jmp     zero,(t0),d0 <exit_sd+0xd0>
  c8:   10 30 08 42     addl    a0,0x41,a0
  cc:   08 00 e0 c3     br      f0 <exit_sd+0xf0>
  d0:   10 30 0f 42     addl    a0,0x79,a0
  d4:   06 00 e0 c3     br      f0 <exit_sd+0xf0>
  d8:   81 00 00 00     bugchk
  dc:   25 01 00 00     call_pal        0x125
        ...
  e8:   ff ff ff c3     br      e8 <exit_sd+0xe8>
  ec:   08 00 1f 22     lda     a0,8
  f0:   00 00 7d a7     ldq     t12,0(gp)
  f4:   00 00 3d 26     ldah    a1,0(gp)
  f8:   01 00 29 21     lda     s0,1(s0)
  fc:   00 00 31 22     lda     a1,0(a1)
 100:   00 40 5b 6b     jsr     ra,(t12),104 <exit_sd+0x104>
...


I believe the problem is static int sd_major(int major_idx) being inlined
into exit_sd(). IIUC the switch statement therein uses sort of a jump table.
And the targets of this jump table can not be resolved because the section
they live in is just discarded.


applying this patch makes the problem go away:

Signed-off-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 01cefbb..adf79ad 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1913,7 +1913,7 @@ err_out:
  *
  *	Note: this function unregisters this driver from the scsi mid-level.
  **/
-static void __exit exit_sd(void)
+static void exit_sd(void)
 {
 	int i;
 


compile and boot tested.

bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: Build error: `.exit.text' referenced in section `.rodata'

[James Bottomley]

On Sun, 2008-05-11 at 15:19 +0000, Thorsten Kranzkowski wrote:
> Hello,
> 
> compiling 2.6.26-rc1 (latest git) on an Alpha DS20 (ev6, everything built in,
> gcc version 4.1.2) fails with the following link errors:
> 
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> make[1]: *** [.tmp_vmlinux1] Error 1
> make: *** [sub-make] Error 2
> 
> 
> The problem also exists in 2.6.25 and probably several previous versions. 
> I didn't try to determine where it started, though.
> 
> 
> Trying to find the root of this problem I tried this:
> 
> bash-3.00$ objdump -r --section=.rodata /usr/src/linux-2.6.26-rc1-ds20/drivers/built-in.o  |grep exit.text
> 0000000000015558 GPREL32           .exit.text+0x0000000000001084
> 000000000001555c GPREL32           .exit.text+0x0000000000001060
> 0000000000015560 GPREL32           .exit.text+0x0000000000001060
> 0000000000015564 GPREL32           .exit.text+0x0000000000001060
> 0000000000015568 GPREL32           .exit.text+0x0000000000001060
> 000000000001556c GPREL32           .exit.text+0x0000000000001060
> 0000000000015570 GPREL32           .exit.text+0x0000000000001060
> 0000000000015574 GPREL32           .exit.text+0x0000000000001060
> 0000000000015578 GPREL32           .exit.text+0x0000000000001068
> 000000000001557c GPREL32           .exit.text+0x0000000000001068
> 0000000000015580 GPREL32           .exit.text+0x0000000000001068
> 0000000000015584 GPREL32           .exit.text+0x0000000000001068
> 0000000000015588 GPREL32           .exit.text+0x0000000000001068
> 000000000001558c GPREL32           .exit.text+0x0000000000001068
> 0000000000015590 GPREL32           .exit.text+0x0000000000001068
> 0000000000015594 GPREL32           .exit.text+0x0000000000001068
> 
> 
> bash-3.00$ objdump -t --section=.exit.text /usr/src/linux-2.6.26-rc1-ds20/drivers/built-in.o  
> 
> ...
> 0000000000000e8c l     F .exit.text     000000000000010c 0x88 exit_st
> 0000000000000f98 l     F .exit.text     000000000000012c 0x88 exit_sd
> 00000000000010c4 l     F .exit.text     0000000000000054 0x88 exit_sr
> 0000000000001118 l     F .exit.text     00000000000000e0 0x88 exit_sg
> 00000000000011f8 l     F .exit.text     0000000000000080 0x88 exit_ch_module
> 0000000000001278 l     F .exit.text     0000000000000050 0x88 ses_exit
> ...
> 
> 
> --> ok looks like exit_sd is the culprit, which is contained in sd.c
> 
> 
> bash-3.00$ objdump -r --section=.rodata /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o 
> 
> ...
> 0000000000000054 GPREL32           .text+0x000000000000316c
> 0000000000000058 GPREL32           .exit.text+0x00000000000000ec
> 000000000000005c GPREL32           .exit.text+0x00000000000000c8
> 0000000000000060 GPREL32           .exit.text+0x00000000000000c8
> 0000000000000064 GPREL32           .exit.text+0x00000000000000c8
> 0000000000000068 GPREL32           .exit.text+0x00000000000000c8
> 000000000000006c GPREL32           .exit.text+0x00000000000000c8
> 0000000000000070 GPREL32           .exit.text+0x00000000000000c8
> 0000000000000074 GPREL32           .exit.text+0x00000000000000c8
> 0000000000000078 GPREL32           .exit.text+0x00000000000000d0
> 000000000000007c GPREL32           .exit.text+0x00000000000000d0
> 0000000000000080 GPREL32           .exit.text+0x00000000000000d0
> 0000000000000084 GPREL32           .exit.text+0x00000000000000d0
> 0000000000000088 GPREL32           .exit.text+0x00000000000000d0
> 000000000000008c GPREL32           .exit.text+0x00000000000000d0
> 0000000000000090 GPREL32           .exit.text+0x00000000000000d0
> 0000000000000094 GPREL32           .exit.text+0x00000000000000d0
> 0000000000000098 GPREL32           .init.text+0x00000000000000a8
> ...
> 
> 
> --> ok, sd.c seems to be right, now where are these symbols actually used?
> 
> 
> objdump -r  /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o
> 
> RELOCATION RECORDS FOR [.exit.text]:
> OFFSET           TYPE              VALUE
> ...
> 00000000000000b0 GPRELHIGH         .rodata+0x0000000000000058
> 00000000000000b4 GPRELLOW          .rodata+0x0000000000000058
> ...
> 
> 
> --> so they are used from inside .exit.text which contains only one function (in sd.o):
> 
> objdump --disassemble -S  --section=.exit.text /usr/src/linux-2.6.26-rc1-ds20/drivers/scsi/sd.o
> 
> ...
>   94:   00 00 ba 27     ldah    gp,0(ra)
>   98:   00 00 bd 23     lda     gp,0(gp)
>   9c:   10 04 ff 47     clr     a0
>   a0:   01 00 5f 20     lda     t1,1
>   a4:   22 f6 41 48     zapnot  t1,0xf,t1
>   a8:   a1 f7 41 40     cmpule  t1,0xf,t0
>   ac:   0a 00 20 e4     beq     t0,d8 <exit_sd+0xd8>
>   b0:   00 00 3d 24     ldah    t0,0(gp)
>   b4:   00 00 21 20     lda     t0,0(t0)
>   b8:   41 04 41 40     s4addq  t1,t0,t0
>   bc:   00 00 21 a0     ldl     t0,0(t0)
>   c0:   01 04 a1 43     addq    gp,t0,t0
>   c4:   02 00 e1 6b     jmp     zero,(t0),d0 <exit_sd+0xd0>
>   c8:   10 30 08 42     addl    a0,0x41,a0
>   cc:   08 00 e0 c3     br      f0 <exit_sd+0xf0>
>   d0:   10 30 0f 42     addl    a0,0x79,a0
>   d4:   06 00 e0 c3     br      f0 <exit_sd+0xf0>
>   d8:   81 00 00 00     bugchk
>   dc:   25 01 00 00     call_pal        0x125
>         ...
>   e8:   ff ff ff c3     br      e8 <exit_sd+0xe8>
>   ec:   08 00 1f 22     lda     a0,8
>   f0:   00 00 7d a7     ldq     t12,0(gp)
>   f4:   00 00 3d 26     ldah    a1,0(gp)
>   f8:   01 00 29 21     lda     s0,1(s0)
>   fc:   00 00 31 22     lda     a1,0(a1)
>  100:   00 40 5b 6b     jsr     ra,(t12),104 <exit_sd+0x104>
> ...
> 
> 
> I believe the problem is static int sd_major(int major_idx) being inlined
> into exit_sd(). IIUC the switch statement therein uses sort of a jump table.
> And the targets of this jump table can not be resolved because the section
> they live in is just discarded.

It's plausible.  However, my version of gcc (4.2.3) doesn't actually
inline this; even when I force it to by adding the inline directive to
sd_major() I don't see the problem.  I suspect it might be a gcc bug

> 
> applying this patch makes the problem go away:
> 
> Signed-off-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 01cefbb..adf79ad 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1913,7 +1913,7 @@ err_out:
>   *
>   *	Note: this function unregisters this driver from the scsi mid-level.
>   **/
> -static void __exit exit_sd(void)
> +static void exit_sd(void)

We can't really do this because that text genuinely does belong in the
exit section.  We might be able to fix it up on the alpha by just adding
the noinline directive to sd_major.  Does this work?

James

---

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 01cefbb..060ba18 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -280,7 +280,7 @@ static struct scsi_driver sd_template = {
  * As we stay compatible with our numbering scheme, we can reuse 
  * the well-know SCSI majors 8, 65--71, 136--143.
  */
-static int sd_major(int major_idx)
+static noinline int sd_major(int major_idx)
 {
 	switch (major_idx) {
 	case 0:

Re: Build error: `.exit.text' referenced in section `.rodata'

[Thorsten Kranzkowski]

On Sun, May 11, 2008 at 11:55:07AM -0500, James Bottomley wrote:
> On Sun, 2008-05-11 at 15:19 +0000, Thorsten Kranzkowski wrote:
> > Hello,
> > 
> > compiling 2.6.26-rc1 (latest git) on an Alpha DS20 (ev6, everything built in,
> > gcc version 4.1.2) fails with the following link errors:
> > 
> >   CC      init/version.o
> >   LD      init/built-in.o
> >   LD      .tmp_vmlinux1
> > `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o


> > I believe the problem is static int sd_major(int major_idx) being inlined
> > into exit_sd(). IIUC the switch statement therein uses sort of a jump table.
> > And the targets of this jump table can not be resolved because the section
> > they live in is just discarded.
> 
> It's plausible.  However, my version of gcc (4.2.3) doesn't actually
> inline this; even when I force it to by adding the inline directive to
> sd_major() I don't see the problem.  I suspect it might be a gcc bug
> 
> > 
> > applying this patch makes the problem go away:
> > 
> > Signed-off-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> > 
> > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > index 01cefbb..adf79ad 100644
> > --- a/drivers/scsi/sd.c
> > +++ b/drivers/scsi/sd.c
> > @@ -1913,7 +1913,7 @@ err_out:
> >   *
> >   *	Note: this function unregisters this driver from the scsi mid-level.
> >   **/
> > -static void __exit exit_sd(void)
> > +static void exit_sd(void)
> 
> We can't really do this because that text genuinely does belong in the
> exit section.  We might be able to fix it up on the alpha by just adding
> the noinline directive to sd_major.  Does this work?

Yes, this works as well! Thanks!

   text    data     bss     dec     hex filename
6834571  504320  397508 7736399  760c4f vmlinux
6835267  504056  397508 7736831  760dff vmlinux-exit_sd-not-in-.exit.text

Tested-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
 
Now I'll update gcc and try again with gcc 4.2.3.

> James
> 
> ---
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 01cefbb..060ba18 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -280,7 +280,7 @@ static struct scsi_driver sd_template = {
>   * As we stay compatible with our numbering scheme, we can reuse 
>   * the well-know SCSI majors 8, 65--71, 136--143.
>   */
> -static int sd_major(int major_idx)
> +static noinline int sd_major(int major_idx)
>  {
>  	switch (major_idx) {
>  	case 0:
> 
> 

Thorsten.

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: Build error: `.exit.text' referenced in section `.rodata'

[Thorsten Kranzkowski]

On Sun, May 11, 2008 at 07:20:07PM +0000, Thorsten Kranzkowski wrote:
> On Sun, May 11, 2008 at 11:55:07AM -0500, James Bottomley wrote:
> > On Sun, 2008-05-11 at 15:19 +0000, Thorsten Kranzkowski wrote:
> > > Hello,
> > > 
> > > compiling 2.6.26-rc1 (latest git) on an Alpha DS20 (ev6, everything built in,
> > > gcc version 4.1.2) fails with the following link errors:
> > > 
> > >   CC      init/version.o
> > >   LD      init/built-in.o
> > >   LD      .tmp_vmlinux1
> > > `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> 
> 
> > > I believe the problem is static int sd_major(int major_idx) being inlined
> > > into exit_sd(). IIUC the switch statement therein uses sort of a jump table.
> > > And the targets of this jump table can not be resolved because the section
> > > they live in is just discarded.
> > 
> > It's plausible.  However, my version of gcc (4.2.3) doesn't actually
> > inline this; even when I force it to by adding the inline directive to
> > sd_major() I don't see the problem.  I suspect it might be a gcc bug
> > 
> > > 
> > > applying this patch makes the problem go away:
> > > 
> > > Signed-off-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> > > 
> > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > > index 01cefbb..adf79ad 100644
> > > --- a/drivers/scsi/sd.c
> > > +++ b/drivers/scsi/sd.c
> > > @@ -1913,7 +1913,7 @@ err_out:
> > >   *
> > >   *	Note: this function unregisters this driver from the scsi mid-level.
> > >   **/
> > > -static void __exit exit_sd(void)
> > > +static void exit_sd(void)
> > 
> > We can't really do this because that text genuinely does belong in the
> > exit section.  We might be able to fix it up on the alpha by just adding
> > the noinline directive to sd_major.  Does this work?
> 
> Yes, this works as well! Thanks!
> 
>    text    data     bss     dec     hex filename
> 6834571  504320  397508 7736399  760c4f vmlinux
> 6835267  504056  397508 7736831  760dff vmlinux-exit_sd-not-in-.exit.text
> 
> Tested-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
>  
> Now I'll update gcc and try again with gcc 4.2.3.


With gcc 4.2.3 I get the same error. The noinline patch fixes it again.

   text    data     bss     dec     hex filename
6721720  624416  397508 7743644  76289c vmlinux-gcc-4.2.3


bye,
Thorsten
 
> > James
> > 
> > ---
> > 
> > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > index 01cefbb..060ba18 100644
> > --- a/drivers/scsi/sd.c
> > +++ b/drivers/scsi/sd.c
> > @@ -280,7 +280,7 @@ static struct scsi_driver sd_template = {
> >   * As we stay compatible with our numbering scheme, we can reuse 
> >   * the well-know SCSI majors 8, 65--71, 136--143.
> >   */
> > -static int sd_major(int major_idx)
> > +static noinline int sd_major(int major_idx)
> >  {
> >  	switch (major_idx) {
> >  	case 0:
> > 
> > 
> 


-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: Build error: `.exit.text' referenced in section `.rodata'

[James Bottomley]

On Mon, 2008-05-12 at 11:52 +0000, Thorsten Kranzkowski wrote:
> On Sun, May 11, 2008 at 07:20:07PM +0000, Thorsten Kranzkowski wrote:
> > On Sun, May 11, 2008 at 11:55:07AM -0500, James Bottomley wrote:
> > > On Sun, 2008-05-11 at 15:19 +0000, Thorsten Kranzkowski wrote:
> > > > Hello,
> > > > 
> > > > compiling 2.6.26-rc1 (latest git) on an Alpha DS20 (ev6, everything built in,
> > > > gcc version 4.1.2) fails with the following link errors:
> > > > 
> > > >   CC      init/version.o
> > > >   LD      init/built-in.o
> > > >   LD      .tmp_vmlinux1
> > > > `.exit.text' referenced in section `.rodata' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
> > 
> > 
> > > > I believe the problem is static int sd_major(int major_idx) being inlined
> > > > into exit_sd(). IIUC the switch statement therein uses sort of a jump table.
> > > > And the targets of this jump table can not be resolved because the section
> > > > they live in is just discarded.
> > > 
> > > It's plausible.  However, my version of gcc (4.2.3) doesn't actually
> > > inline this; even when I force it to by adding the inline directive to
> > > sd_major() I don't see the problem.  I suspect it might be a gcc bug
> > > 
> > > > 
> > > > applying this patch makes the problem go away:
> > > > 
> > > > Signed-off-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> > > > 
> > > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > > > index 01cefbb..adf79ad 100644
> > > > --- a/drivers/scsi/sd.c
> > > > +++ b/drivers/scsi/sd.c
> > > > @@ -1913,7 +1913,7 @@ err_out:
> > > >   *
> > > >   *	Note: this function unregisters this driver from the scsi mid-level.
> > > >   **/
> > > > -static void __exit exit_sd(void)
> > > > +static void exit_sd(void)
> > > 
> > > We can't really do this because that text genuinely does belong in the
> > > exit section.  We might be able to fix it up on the alpha by just adding
> > > the noinline directive to sd_major.  Does this work?
> > 
> > Yes, this works as well! Thanks!
> > 
> >    text    data     bss     dec     hex filename
> > 6834571  504320  397508 7736399  760c4f vmlinux
> > 6835267  504056  397508 7736831  760dff vmlinux-exit_sd-not-in-.exit.text
> > 
> > Tested-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> >  
> > Now I'll update gcc and try again with gcc 4.2.3.
> 
> 
> With gcc 4.2.3 I get the same error. The noinline patch fixes it again.
> 
>    text    data     bss     dec     hex filename
> 6721720  624416  397508 7743644  76289c vmlinux-gcc-4.2.3

OK, so it's an unfixed bug in gcc, and it looks to be specific to the
alpha backend.  if the compiler chooses to inline a function, it has to
respect the sectional (and other constraints) of the outer function.
Can someone file a bug report with the relevant compiler people?

Jmaes

Re: Build error: `.exit.text' referenced in section `.rodata'

[Ivan Kokshaysky]

On Mon, May 12, 2008 at 09:01:44AM -0500, James Bottomley wrote:
> > With gcc 4.2.3 I get the same error. The noinline patch fixes it again.
> > 
> >    text    data     bss     dec     hex filename
> > 6721720  624416  397508 7743644  76289c vmlinux-gcc-4.2.3
> 
> OK, so it's an unfixed bug in gcc, and it looks to be specific to the
> alpha backend.

No, other architectures are just lucky that the compiler decides
a) not to generate a jump table for switch statement in sd_major() and/or
b) not to inline this function.

I have a similar test case that fails on x86 as well.

> if the compiler chooses to inline a function, it has to
> respect the sectional (and other constraints) of the outer function.
> Can someone file a bug report with the relevant compiler people?

It would be good, but in the meantime the 'noinline' fix seems to be
a most sensible option...

Ivan.

Re: Build error: `.exit.text' referenced in section `.rodata'

[James Bottomley]

On Tue, 2008-05-13 at 18:31 +0400, Ivan Kokshaysky wrote:
> On Mon, May 12, 2008 at 09:01:44AM -0500, James Bottomley wrote:
> > > With gcc 4.2.3 I get the same error. The noinline patch fixes it again.
> > > 
> > >    text    data     bss     dec     hex filename
> > > 6721720  624416  397508 7743644  76289c vmlinux-gcc-4.2.3
> > 
> > OK, so it's an unfixed bug in gcc, and it looks to be specific to the
> > alpha backend.
> 
> No, other architectures are just lucky that the compiler decides
> a) not to generate a jump table for switch statement in sd_major() and/or
> b) not to inline this function.
> 
> I have a similar test case that fails on x86 as well.

But if that's true then the whole basis for our section based discards
is bogus, because the statement generating the jump table could be
inside the actual function body instead of being inlined, so if it's
failing on x86 as well, we likely need it fixed there too.

> > if the compiler chooses to inline a function, it has to
> > respect the sectional (and other constraints) of the outer function.
> > Can someone file a bug report with the relevant compiler people?
> 
> It would be good, but in the meantime the 'noinline' fix seems to be
> a most sensible option...

We can certainly add it as a short term option.  However, given the push
in certain quarters to make even more use of sections as a means of
discarding code, we're going to have to ask someone to fix the compiler.

James

Re: Build error: `.exit.text' referenced in section `.rodata'

[Ivan Kokshaysky]

On Tue, May 13, 2008 at 09:59:17AM -0500, James Bottomley wrote:
> But if that's true then the whole basis for our section based discards
> is bogus, because the statement generating the jump table could be
> inside the actual function body instead of being inlined, so if it's
> failing on x86 as well, we likely need it fixed there too.

Correct.

> > It would be good, but in the meantime the 'noinline' fix seems to be
> > a most sensible option...
> 
> We can certainly add it as a short term option.  However, given the push
> in certain quarters to make even more use of sections as a means of
> discarding code, we're going to have to ask someone to fix the compiler.

Then maybe building with -fno-jump-tables option would be better solution.
I don't think that it will have a noticeable impact on code size or
performance, especially on x86.

So we need something like this (assuming gcc eventually gets fixed,
say gcc 4.5 ;)

KBUILD_CFLAGS	+= $(call cc-ifversion, -lt, 0405, \
			$(call cc-option, -fno-jump-tables))

Ivan.

Re: Build error: `.exit.text' referenced in section `.rodata'

[James Bottomley]

On Wed, 2008-05-14 at 00:06 +0400, Ivan Kokshaysky wrote:
> On Tue, May 13, 2008 at 09:59:17AM -0500, James Bottomley wrote:
> > But if that's true then the whole basis for our section based discards
> > is bogus, because the statement generating the jump table could be
> > inside the actual function body instead of being inlined, so if it's
> > failing on x86 as well, we likely need it fixed there too.
> 
> Correct.
> 
> > > It would be good, but in the meantime the 'noinline' fix seems to be
> > > a most sensible option...
> > 
> > We can certainly add it as a short term option.  However, given the push
> > in certain quarters to make even more use of sections as a means of
> > discarding code, we're going to have to ask someone to fix the compiler.
> 
> Then maybe building with -fno-jump-tables option would be better solution.
> I don't think that it will have a noticeable impact on code size or
> performance, especially on x86.
> 
> So we need something like this (assuming gcc eventually gets fixed,
> say gcc 4.5 ;)
> 
> KBUILD_CFLAGS	+= $(call cc-ifversion, -lt, 0405, \
> 			$(call cc-option, -fno-jump-tables))

This is way beyond a SCSI issue.  Time to take it to linux-arch I
think ... do you want to do the honours?

James