public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
Date: Fri, 11 Jun 2004 19:12:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl> (raw)
In-Reply-To: <40C9F7F0.50501@avtrex.com>

On Fri, 11 Jun 2004, David Daney wrote:

> I guess I didn't fully read the comment above this section of code.
> 
>     /*
>      * There is the ancient bug in the MIPS assemblers that the break
>      * code starts left to bit 16 instead to bit 6 in the opcode.
>      * Gas is bug-compatible ...
>      */
> 
> I am using gcc-3.3.1/binutils-2.15.  With this toolchain, I get break 
> instructions that comply with the MIPS documentation for break instructions:

 Well, I did some research and I'm afraid it dates back to a commit from
2000-12-01, when a different interpretation of "break" was introduced for
the MIPS32/64 ISA.  So the interpretation of the "break" instruction
depends on the "-march" setting and moreover, only for instructions
requested explicitly.  For ones emitted implicitly as a result of division
and multiplication macros, the interpretation is always the "traditional"
one (the "c" vs the "B" code).

> 00000000 <do_div>:
>    0:   3c1c0000        lui     gp,0x0
>    4:   279c0000        addiu   gp,gp,0
>    8:   0399e021        addu    gp,gp,t9
>    c:   0085001a        div     zero,a0,a1
>   10:   14a00002        bnez    a1,1c <do_div+0x1c>
>   14:   00000000        nop
>   18:   000001cd        break   0x7
>   1c:   00001012        mflo    v0
>   20:   03e00008        jr      ra
>   24:   00000000        nop
>  
> 
> What to do?

1. I think Linux can intercept both the "traditional" and MIPS32/64 values
-- break codes are not used that extensively this would risk running out
of them.  The set of known ones can be seen in <asm/break.h>.  However,
this won't aid userland trying to interpret code (there may be none such, 
though).

2. Gas should definitely use the codes consistently.  And it's a pity the
ABI got broken -- I think another mnemonic should have been chosen for the
correct implementation of "break", available to any ISA.

3. GCC should probably use traps for anything above MIPS I, anyway.  
Perhaps with an option, like for gas, to select the alternative.

4. Perhaps something else.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

  reply	other threads:[~2004-06-11 19:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <40C9F5A4.2050606@avtrex.com>
     [not found] ` <40C9F5FE.8030607@avtrex.com>
2004-06-11 18:22   ` David Daney
2004-06-11 19:12     ` Maciej W. Rozycki [this message]
     [not found]       ` <mailpost.1086981251.16853@news-sj1-1>
2004-06-11 19:28         ` cgd
2004-06-11 19:50           ` Maciej W. Rozycki
2004-06-11 20:52             ` David Daney
2004-06-11 21:12               ` [Patch] (revised patch) " David Daney
2004-06-13  8:33                 ` Geert Uytterhoeven
2004-06-14 12:52                   ` Maciej W. Rozycki
2004-06-22 21:30           ` [Patch] " Maciej W. Rozycki
2004-06-23 19:33             ` David Daney
2004-06-23 19:38               ` Maciej W. Rozycki
2004-06-24 10:39             ` Richard Sandiford
2004-06-24 18:34               ` Maciej W. Rozycki
     [not found]                 ` <mailpost.1088102121.25381@news-sj1-1>
2004-06-24 18:47                   ` cgd
2004-06-28 13:46                     ` Maciej W. Rozycki
2004-06-28 15:19 cgd
2004-06-28 15:36 ` Maciej W. Rozycki
2004-07-19 14:22 ` Maciej W. Rozycki
     [not found]   ` <mailpost.1090246948.15046@news-sj1-1>
2004-07-19 15:19     ` cgd
2004-07-19 15:42       ` Maciej W. Rozycki
2004-07-19 23:29   ` Thiemo Seufer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl \
    --to=macro@ds2.pg.gda.pl \
    --cc=binutils@sources.redhat.com \
    --cc=ddaney@avtrex.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).