This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] MIPS: Trap instructions in division/multiplyexpansions

At Wed, 10 Jul 2002 00:55:57 +0000 (UTC), "Ralf Baechle" wrote:
> On Mon, Jul 08, 2002 at 02:45:04PM -0700, wrote:
> > >  I believe it would be correct to embed a non-zero code in trap
> > > instructions used in division/multiply macro expansions, similarly to how
> > > breakpoint codes (6 and 7) are used in the non-trap versions.  The
> > > following patch implements it.  At least MIPS/Linux extracts these codes
> > > from both break and trap opcodes and uses them to determine whether
> > > SIGTRAP or SIGFPE should be sent.  Any comments? 
> > 
> > What do other OSes do for these cases?  (In particular, i'm wondering
> > what the SGI assembler does.)
> The trap codes Linux/MIPS is using in the kernel are the same as in IRIX;
> they're generated by the IRIX assembler as well.

Thank you for the example of ... some unknown assembler generating
break codes.  But, that's not really relevant to the question.

The question is not whether the _codes_ y'all happened to choose are
the same; that's pretty obvious.

I was wondering if this was following prior art for use of the trap
instruction codes, or if it was inventing something new.  For
instance, questions like the following:

* does IRIX or another 'common' MIPS compiler have a "-trap"-like
flag, and what does _it_ generate?  I don't _see_ an option to do
this, w/ the IRIX assembler (don't have current version though)... but
I just looked at an old version of IRIX's compiler output (n32, i
guess), which will produce code like:

[   4] 0x   0:  00 85 00 1a    div $0,a0,a1
[   4] 0x   4:  00 00 10 12    mflo v0
[   4] 0x   8:  03 e0 00 08    jr ra
[   4] 0x   c:  00 a0 01 f4    teq a1,zero,7

* will this _break_ other systems implementation of these checks that
use the trap instructions?

So, I guess in fact this proposal does follow prior art (of some close
form, at least).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]