delete unused file

Remove nowhere referenced file. (egrep "filename\." didn't find anything)

---

 kj/include/asm-mips/it8172/it8172_lpc.h |   29 -----------------------------
 1 files changed, 29 deletions(-)

diff -L include/asm-mips/it8172/it8172_lpc.h -puN include/asm-mips/it8172/it8172_lpc.h~remove_file-include_asm_mips_it8172_it8172_lpc.h /dev/null
@@ -1,29 +0,0 @@
-/*
- *
- * BRIEF MODULE DESCRIPTION
- *	IT8172 system controller defines.
- *
- * Copyright 2000 MontaVista Software Inc.
- * Author: MontaVista Software, Inc.
- *         	[email protected] or [email protected]
- *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  option) any later version.
- *
- *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
- *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
- *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
- *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the  GNU General Public License along
- *  with this program; if not, write  to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */

_

Applied,

Ralf

Hello !

When building 2.6.10, the assembler (2.13.2.1) gets confused by a "b target2" (compiler generated) immediately following a "beqzl target1" (inline assembly macro), and reorders these instructions (with wrong address calculation too) to an infinite loop.
(Well, not really infinite - after about ten minutes some timer interrupt makes an end to it by a null-pointer dereference in __queue_work() ;-) This bug is rather unreliable though, going away with minimal, unintentional code changes, unexpectedly reappearing after some later rebuild...

Was this behaviour already observed elsewhere ? Is it fixed in some newer assembler version ? Or should i just be content with it and work around with appropriate "nop"s in the concerned inline-assembly macros ? ... ?

as -EB -G 0 -mips4 -O2 -g0 -64 -mcpu=r8000 -v -64 -non_shared -64 -march=r8000 -mips4 --trap -o kernel/.tmp_fork.o GNU assembler version 2.13.2.1 (mips64-ip28-linux-gnu) using BFD version 2.13.2.1
GNU assembler version 2.13.2.1 (mips64-linux) using BFD version 2.13.2.1

Here are examples of what the assembler receives from the compiler, and what it produces:

a80000002003a6c0 <copy_process>:
...

	.set	macro
	.set	reorder
	cache 0x14,0($sp)	# Cache Barrier
 #APP
	1:	lld	$3, 256($4)	# atomic64_add
	addu	$3, $2
	scd	$3, 256($4)
	beqzl	$3, 1b
 #NO_APP
	b	$L5881
$L5887:
	 # Cache Barrier omitted.
	move	$5,$0
$L5881:
	...

a80000002003a944: bfb40000 cache 0x14,0(sp)
a80000002003a948: d0830100 lld v1,256(a0)
a80000002003a94c: 00621821 addu v1,v1,v0
a80000002003a950: f0830100 scd v1,256(a0)
a80000002003a954 <!>: 1000ffff b a80000002003a954 <$L6939+0xe4>
a80000002003a958: 00000000 nop
a80000002003a95c: 50600000 beqzl v1,a80000002003a960 <$L5887>
a80000002003a960 <$L5887>:
a80000002003a960: 0000282d move a1,zero
a80000002003a964 <$L5881>:
...

#APP

	1:	ll	$5, 0($2)	# atomic_add
	addu	$5, $3
	sc	$5, 0($2)
	beqzl	$5, 1b
 #NO_APP
	b	$L6092
$L6057:
	...
$L6092:
	...

a80000002003abe4: c0450000 ll a1,0(v0)
a80000002003abe8 <!>: 00a32821 addu a1,a1,v1
a80000002003abec: e0450000 sc a1,0(v0)
a80000002003abf0: 1000fffd b a80000002003abe8 <$L6045+0x70>
a80000002003abf4: 00000000 nop
a80000002003abf8: 50a00000 beqzl a1,a80000002003abfc <$L6057>
a80000002003abfc <$L6057>:
...

#APP

	1:	ll	$5, 4($2)	# atomic_add
	addu	$5, $3
	sc	$5, 4($2)
	beqzl	$5, 1b
 #NO_APP
	b	$L6480
$L6411:
	...
$L6480:
	...

a80000002003aedc: c0450004 ll a1,4(v0)
a80000002003aee0: 00a32821 addu a1,a1,v1
a80000002003aee4 <!>: e0450004 sc a1,4(v0)
a80000002003aee8: 1000fffe b a80000002003aee4 <$L6401+0x54>
a80000002003aeec: 00000000 nop
a80000002003aef0: 50a00000 beqzl a1,a80000002003aef4 <$L6411>
a80000002003aef4 <$L6411>:
...

with kind regards

pf

[snip]

Fixed in current binutils CVS, IIRC both 2.15 branch and trunk. The older binutils tarball at linux-mips.org was also fixed.

You should upgrade to something newer than 2.13. :-)

Note that those arguments are partially contradicting each other.

-mips4 -64 -mcpu=r8000 -64 -64 -march=r8000 -mips4

is (with 2.15 gas) better expressed as

-mabi=64 -march=mips4

or, more suitable for r10000, with

-mabi=64 -march=r10000

Thiemo