Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches

Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches

[ljrittle]

Synopsis: MIPS cross-assembler reports error for constant PC-relative branches

State-Changed-From-To: open->closed
State-Changed-By: ljrittle
State-Changed-When: Mon Jun 11 20:55:21 2001
State-Changed-Why:
    At worst, this is an assembler error.  At best, it was
    a user error.  In either case, per e-mail response
    from cgd@sibyte.com (Chris G. Demetriou), this issus was
    reported to the wrong gnat database.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2467&database=gcc

Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches

[Chris G. Demetriou]

The following reply was made to PR target/2467; it has been noted by GNATS.

From: cgd@sibyte.com (Chris G. Demetriou)
To: vvortex1@home.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: target/2467: MIPS cross-assembler reports error for constant PC-relative branches
Date: 03 Apr 2001 17:13:35 -0700

 vvortex1@home.com writes:
 > When given a PC-relative branch instruction with a numeric immediate, such as "bne $0, $0, 16", the MIPS cross-assembler correctly parses the expression but fails to generate object code. It reports "Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file format". Strictly speaking, no relocation information is necessary because the value of the immediate field is already known. This error is generated in all known emulation modes.
 > >How-To-Repeat:
 > Contents of broken.s:
 > bne $0, $0, 8
 > nop
 > nop
 > nop
 > nop
 > ------
 > 
 > To reproduce, run:
 > % mips64orion-rtems-as broken.s
 > None of the configuration options seem to have any effect on this glitch.
 > >Fix:
 > Beats me ;-) The assembler should simply store the supplied numeric operand shifted right two places.
 
 (1) why have you reported this as a GCC bug?
 
 (2) in general, I suspect that what's happening here is that it's
 taking '8' as the address '8', and trying to convert that to a branch
 using a PC-relative relocation.
 
 
 I would guess that what you mean here is ".+8" or similar.
 
 I find that, indeed, with current-ish assemblers:
 
         bne     $0, $0, .+8
 
 assembles into:
 
    0:   14000001        bnez    $zero,0x8
    4:   00000000        nop
 
 which is, i believe, what you want.
 
 
 cgd

target/2467: MIPS cross-assembler reports error for constant PC-relative branches

[vvortex1]

>Number:         2467
>Category:       target
>Synopsis:       MIPS cross-assembler reports error for constant PC-relative branches
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 02 23:36:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     vvortex1@home.com
>Release:        2.10
>Organization:
>Environment:
FreeBSD 4.2 on i386 architecture. Also tested with Solaris 7 on Sparc architecture.
GNU assembler 2.10 (mips64orion-rtems) using BFD version 2.10.
>Description:
When given a PC-relative branch instruction with a numeric immediate, such as "bne $0, $0, 16", the MIPS cross-assembler correctly parses the expression but fails to generate object code. It reports "Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file format". Strictly speaking, no relocation information is necessary because the value of the immediate field is already known. This error is generated in all known emulation modes.
>How-To-Repeat:
Contents of broken.s:
bne $0, $0, 8
nop
nop
nop
nop
------

To reproduce, run:
% mips64orion-rtems-as broken.s
None of the configuration options seem to have any effect on this glitch.
>Fix:
Beats me ;-) The assembler should simply store the supplied numeric operand shifted right two places.
>Release-Note:
>Audit-Trail:
>Unformatted: