Re: How to fix false positives on references to discarded text/data?

[Andrew Morton <akpm@zip.com.au>]

Keith Owens wrote:
> 
> gcc/as generates worse code for the local branches in the out of line
> subsection.  With .text.lock we get
> 
>    0:   80 bd f8 00 00 00 00    cmpb   $0x0,0xf8(%ebp)
>    7:   f3 90                   repz nop
>    9:   7e f5                   jle    0 <.text.lock>           <=== 2 bytes
>    b:   e9 ca 01 00 00          jmp    1da <.text.lock+0x1da>
> 
> With .subsection 1 it generates
> 
> .text.lock.es1371:
> 6387:   80 bd f8 00 00 00 00    cmpb   $0x0,0xf8(%ebp)
> 638e:   f3 90                   repz nop
> 6390:   0f 8e f1 ff ff ff       jle    6387 <.text.lock.es1371> <=== 6 bytes
> 6396:   e9 33 9e ff ff          jmp    1ce <set_adc_rate+0x8e>
> 
> The inline code is unchanged, it is only the out of line code that is
> bigger.  IMHO the subsection difference is a gcc/as bug which should
> not stop us using this fix.

I don't see this.   With egcs-1.1.2 and assembler 2.11.90.0.25,
your patch actually (and mysteriously) shrunk the kernel by 500
bytes - the new .text is a little smaller than the sum of the
old .text and .text.lock.

As you say, if the assembler is generating long-form branches for
the `jle' in the below sequence, we have a problem.

#APP
        
1:      lock ; decb timerlist_lock
        js 2f
.subsection 1
.ifndef .text.lock.bust_spinlocks
.text.lock.bust_spinlocks:
.endif
2:      cmpb $0,timerlist_lock
        rep;nop
        jle 2b
        jmp 1b
.previous

Keith, perhaps you could ship a .s file and a version number to HJ?

-