* [patch 4/9] delete unused file
@ 2004-12-25 17:24 domen
2004-12-27 12:44 ` Ralf Baechle
0 siblings, 1 reply; 4+ messages in thread
From: domen @ 2004-12-25 17:24 UTC (permalink / raw)
To: ralf; +Cc: linux-mips, domen
Remove nowhere referenced file. (egrep "filename\." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
---
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.
- * ppopov@mvista.com or source@mvista.com
- *
- * 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.
- */
_
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch 4/9] delete unused file
2004-12-25 17:24 [patch 4/9] delete unused file domen
@ 2004-12-27 12:44 ` Ralf Baechle
2004-12-31 1:06 ` Confused assembler Peter Fuerst
0 siblings, 1 reply; 4+ messages in thread
From: Ralf Baechle @ 2004-12-27 12:44 UTC (permalink / raw)
To: domen; +Cc: linux-mips
On Sat, Dec 25, 2004 at 06:24:59PM +0100, domen@coderock.org wrote:
> Remove nowhere referenced file. (egrep "filename\." didn't find anything)
>
> Signed-off-by: Domen Puncer <domen@coderock.org>
> ---
>
>
> kj/include/asm-mips/it8172/it8172_lpc.h | 29 -----------------------------
Applied,
Ralf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Confused assembler
2004-12-27 12:44 ` Ralf Baechle
@ 2004-12-31 1:06 ` Peter Fuerst
2004-12-31 16:30 ` Thiemo Seufer
0 siblings, 1 reply; 4+ messages in thread
From: Peter Fuerst @ 2004-12-31 1:06 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Confused assembler
2004-12-31 1:06 ` Confused assembler Peter Fuerst
@ 2004-12-31 16:30 ` Thiemo Seufer
0 siblings, 0 replies; 4+ messages in thread
From: Thiemo Seufer @ 2004-12-31 16:30 UTC (permalink / raw)
To: pf; +Cc: linux-mips
Peter Fuerst wrote:
>
>
> 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.
[snip]
> Was this behaviour already observed elsewhere ? Is it fixed in some newer
> 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
> with appropriate "nop"s in the concerned inline-assembly macros ? ... ?
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-12-31 16:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-25 17:24 [patch 4/9] delete unused file domen
2004-12-27 12:44 ` Ralf Baechle
2004-12-31 1:06 ` Confused assembler Peter Fuerst
2004-12-31 16:30 ` Thiemo Seufer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox