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

Andrew Morton (akpm@zip.com.au)
Sun, 23 Dec 2001 21:44:32 -0800


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?

-
-
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/