Subject: [patch 4/9] delete unused file

From: [email-masked]
Date: Sat, 25 Dec 2004 18:24:59 +0100

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

Signed-off-by: Domen Puncer <[email-masked]>
---

 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
--- kj/include/asm-mips/it8172/it8172_lpc.h
+++ /dev/null	2004-12-24 01:21:08.000000000 +0100
@@ -1,29 +0,0 @@
-/*
- *
- * BRIEF MODULE DESCRIPTION
- *	IT8172 system controller defines.
- *
- * Copyright 2000 MontaVista Software Inc.
- * Author: MontaVista Software, Inc.
- *         	[email-masked] or [email-masked]
- *
- *  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.
- */
_

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 27 Dec 2004 13:44:35 +0100

>  kj/include/asm-mips/it8172/it8172_lpc.h |   29 -----------------------------

Applied,

  Ralf

---

From: Peter Fuerst <[email-masked]>
Date: Fri, 31 Dec 2004 02:06:02 +0100 (CET)

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

---

From: Thiemo Seufer <[email-masked]>
Date: Fri, 31 Dec 2004 17:30:09 +0100

> macro), and reorders these instructions (with wrong address calculation too)
[snip]
> assembler version ?

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

> Or should i just be content with it and work around

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

> as -EB -G 0 -mips4 -O2 -g0 -64 -mcpu=r8000 -v -64 -non_shared -64 -march=r8000 -mips4 --trap -o kernel/.tmp_fork.o

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