This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
The current gas is broken (Re: The current binutils in CVS is broken on Linux/mips)
On Sun, Sep 29, 2002 at 08:48:08AM -0700, H. J. Lu wrote:
> On Sun, Sep 29, 2002 at 08:20:21AM -0700, H. J. Lu wrote:
> > On Sat, Sep 28, 2002 at 07:16:53PM -0700, H. J. Lu wrote:
> > > On Sat, Sep 28, 2002 at 10:13:17PM -0400, Daniel Jacobowitz wrote:
> > > > On Sat, Sep 28, 2002 at 04:17:04PM -0700, H. J. Lu wrote:
> > > > > I recompiled my mipsel kernel with binutils in CVS as of 20020928. The
> > > > > resulting kernel doesn't work. I got
> > > > >
> > > > > Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn,
> > > > > line:
> > > > > $0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > > > $8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > > > $16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > > > $24: 00000000 00000000 00000000 00000000 00000000 00000000
> > > > > Hi : 00000000
> > > > > Lo : 00000000
> > > > > epc : 00000000 Not tainted
> > > > > Status: 00000000
> > > > > Cause : 00000000
> > > > > Process sleep (pid: 16, stackpage=87e8c000)
> > > >
> > > > Could you try with the 2.13.1-branch - I believe it should be fine but
> > > > I haven't tested MIPS in a few merges.
> > > >
> > >
> > > I don't have resources to try 2.13.1. The Linux binutils 2.13.90.0.4
> > > based on 20020814 CVS is ok. I will try to fix CVS.
> > >
> >
> > Linker seems ok. It is as which is broken.
> >
> >
> > H.J.
>
> Here is the diff. The code looks like
>
> LEAF(mips_atomic_set)
> andi v0, a1, 3 # must be word aligned
> bnez v0, bad_alignment
> ....
> LEAF(sys_sysmips)
> beq a0, MIPS_ATOMIC_SET, mips_atomic_set
> j _sys_sysmips
> END(sys_sysmips)
>
> It is assembled with
>
> # mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/export/linux/src/kernel/mips/mipsel/include -I /export/linux/src/kernel/mips/mipsel/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mtune=r4600 -mips2 -Wa,--trap -c -o scall_o32.o scall_o32.S
>
> My patch:
>
> http://sources.redhat.com/ml/binutils/2002-09/msg00421.html
>
> fixes the Linux kernel. Eric, could you please find a way to fix it?
>
> Thanks.
>
>
> H.J.
> ---
> 1 2 differ: char 9127, line 328
> ./arch/mips/kernel/scall_o32.o
> --- 1 Sun Sep 29 08:28:08 2002
> +++ 2 Sun Sep 29 08:28:08 2002
> @@ -325,7 +325,8 @@ Disassembly of section .text:
>
> 0000042c <sys_sysmips>:
> 42c: 240107d1 li at,2001
> - 430: 1081ffd8 beq a0,at,394 <mips_atomic_set>
> + 430: 10810390 beq a0,at,1274 <out+0xd7c>
> + 430: R_MIPS_PC16 mips_atomic_set
> 434: 00000000 nop
> 438: 08000000 j 0 <handle_sys>
> 438: R_MIPS_26 _sys_sysmips
> 1 2 differ: char 239806, line 7177
Alan, I believe your patch
http://sources.redhat.com/ml/binutils/2002-08/msg00611.html
doesn't work too well. The problem is the gas relocation is very
fragile. Any changes to the gas relocation will potentially break
things. It has been discussed many times before. There are even
documented in bfd:
The assembler used @samp{bfd_perform_relocation} for a while. This
turned out to be the wrong thing to do, since
@samp{bfd_perform_relocation} was written to handle relocations on an
existing object file, while the assembler needed to create relocations
in a new object file. The assembler was changed to use the new function
@samp{bfd_install_relocation} instead, and @samp{bfd_install_relocation}
was created as a copy of @samp{bfd_perform_relocation}.
Unfortunately, the work did not progress any farther, so
@samp{bfd_install_relocation} remains a simple copy of
@samp{bfd_perform_relocation}, with all the odd special cases and
confusing code. This again is difficult to change, because again any
change can affect any assembler target, and so is difficult to test.
In the case of mips, the addend for this file is wrong:
---branch-misc-2.s---
.globl g1 .text
.text
.space 20 # <----- Take it out, addend will be fine.
g1:
.space 20
x:
bal g1
---
when compiled with
# ./as-new -g0 -v -KPIC -o branch-misc-2.o branch-misc-2.s
If I remembered right, it has something to do with addend added twice.
Several years ago, I had the pleasure to fix a COFF relocation bug.
It was ugly. I am afraid your patch may have broken other targets in
some very strange ways. Could you please look into it?
Thanks.
H.J.