* RFA: ARM: Implement __builtin_trap
@ 2010-09-08 6:10 Mark Mitchell
2010-09-08 23:05 ` Mike Stump
0 siblings, 1 reply; 16+ messages in thread
From: Mark Mitchell @ 2010-09-08 6:10 UTC (permalink / raw)
To: gcc-patches, rearnshaw, paul
This patch implements __builtin_trap for ARM. The default, for
architectures that do not provide a "trap" instruction, is to call
abort. Executing an invalid instruction is a faster, smaller way to
crash.
OK to apply?
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
2010-09-07 Mark Mitchell <mark@codesourcery.com>
* config/arm/arm.md (trap): New pattern.
2010-09-07 Mark Mitchell <mark@codesourcery.com>
* gcc.target/arm/builtin-trap.c: New.
* gcc.target/arm/thumb-builtin-trap.c: Likewise.
# gcc diff
pushd /scratch/mitchell/builds/fsf-mainline/src/gcc-mainline
svn diff
Index: gcc/testsuite/gcc.target/arm/thumb-builtin-trap.c
===================================================================
--- gcc/testsuite/gcc.target/arm/thumb-builtin-trap.c (revision 0)
+++ gcc/testsuite/gcc.target/arm/thumb-builtin-trap.c (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-mthumb" } */
+
+void trap ()
+{
+ __builtin_trap ();
+}
+
+/* { dg-final { scan-assembler "0xdeff" } } */
Index: gcc/testsuite/gcc.target/arm/builtin-trap.c
===================================================================
--- gcc/testsuite/gcc.target/arm/builtin-trap.c (revision 0)
+++ gcc/testsuite/gcc.target/arm/builtin-trap.c (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm32 } */
+
+void trap ()
+{
+ __builtin_trap ();
+}
+
+/* { dg-final { scan-assembler "0xe7ffffff" } } */
Index: gcc/config/arm/arm.md
===================================================================
--- gcc/config/arm/arm.md (revision 163924)
+++ gcc/config/arm/arm.md (working copy)
@@ -8496,6 +8496,26 @@
(const_int 4)))]
)
+;; Generate an invalid instruction. The instructions chosen are
+;; documented as permanently UNDEFINED, so we can rely on the fact
+;; that no future version of the architecture will use them. The
+;; instructions used are chosen so as to be distinct from he
+;; instructions that the Linux kernel interprets as software
+;; breakpoints.
+(define_insn "trap"
+ [(trap_if (const_int 1) (const_int 0))]
+ ""
+ "*
+ if (TARGET_ARM)
+ return \".inst\\t0xe7ffffff\";
+ else
+ return \".inst\\t0xdeff\";
+ "
+ [(set (attr "length")
+ (if_then_else (eq_attr "is_thumb" "yes")
+ (const_int 2)
+ (const_int 4)))]
+)
\f
;; Patterns to allow combination of arithmetic, cond code and shifts
popd
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-08 6:10 RFA: ARM: Implement __builtin_trap Mark Mitchell
@ 2010-09-08 23:05 ` Mike Stump
2010-09-08 23:18 ` Mark Mitchell
0 siblings, 1 reply; 16+ messages in thread
From: Mike Stump @ 2010-09-08 23:05 UTC (permalink / raw)
To: mark; +Cc: gcc-patches, rearnshaw, paul
On Sep 7, 2010, at 9:12 PM, Mark Mitchell wrote:
> This patch implements __builtin_trap for ARM. The default, for
> architectures that do not provide a "trap" instruction, is to call
> abort. Executing an invalid instruction is a faster, smaller way to
> crash.
Would be nice for arm to allocate (and document) some short sequence that will never be used in future ISA enhancements, as otherwise old binaries that should die, would then just do whatever new instruction was added.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-08 23:05 ` Mike Stump
@ 2010-09-08 23:18 ` Mark Mitchell
2010-09-09 18:34 ` David Daney
2010-09-09 19:30 ` Daniel Jacobowitz
0 siblings, 2 replies; 16+ messages in thread
From: Mark Mitchell @ 2010-09-08 23:18 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc-patches, rearnshaw, paul
On 9/8/2010 3:59 PM, Mike Stump wrote:
> On Sep 7, 2010, at 9:12 PM, Mark Mitchell wrote:
>> This patch implements __builtin_trap for ARM. The default, for
>> architectures that do not provide a "trap" instruction, is to call
>> abort. Executing an invalid instruction is a faster, smaller way to
>> crash.
> Would be nice for arm to allocate (and document) some short sequence that will never be used in future ISA enhancements, as otherwise old binaries that should die, would then just do whatever new instruction was added.
The instructions I chose are documented as such. That's why I wrote:
;; Generate an invalid instruction. The instructions chosen are
;; documented as permanently UNDEFINED, so we can rely on the fact
;; that no future version of the architecture will use them.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-08 23:18 ` Mark Mitchell
@ 2010-09-09 18:34 ` David Daney
2010-09-09 18:46 ` Mark Mitchell
2010-09-09 19:30 ` Daniel Jacobowitz
1 sibling, 1 reply; 16+ messages in thread
From: David Daney @ 2010-09-09 18:34 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Mike Stump, gcc-patches, rearnshaw, paul
On 09/08/2010 04:01 PM, Mark Mitchell wrote:
> On 9/8/2010 3:59 PM, Mike Stump wrote:
>> On Sep 7, 2010, at 9:12 PM, Mark Mitchell wrote:
>>> This patch implements __builtin_trap for ARM. The default, for
>>> architectures that do not provide a "trap" instruction, is to call
>>> abort. Executing an invalid instruction is a faster, smaller way to
>>> crash.
>
>> Would be nice for arm to allocate (and document) some short sequence that will never be used in future ISA enhancements, as otherwise old binaries that should die, would then just do whatever new instruction was added.
>
> The instructions I chose are documented as such. That's why I wrote:
>
> ;; Generate an invalid instruction. The instructions chosen are
> ;; documented as permanently UNDEFINED, so we can rely on the fact
> ;; that no future version of the architecture will use them.
>
> Thanks,
>
I saw that, and I have no objections to that patch. But I was thinking
that this essentially augments the ABI. Could or should this be
coordinated with the maintainers of any ARM ABIs?
David Daney
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 18:34 ` David Daney
@ 2010-09-09 18:46 ` Mark Mitchell
2010-09-09 18:49 ` Chris Lattner
0 siblings, 1 reply; 16+ messages in thread
From: Mark Mitchell @ 2010-09-09 18:46 UTC (permalink / raw)
To: David Daney; +Cc: Mike Stump, gcc-patches, rearnshaw, paul
On 9/9/2010 11:20 AM, David Daney wrote:
> I saw that, and I have no objections to that patch. But I was thinking
> that this essentially augments the ABI. Could or should this be
> coordinated with the maintainers of any ARM ABIs?
Do other psABIs document how __builtin_trap is implemented?
Richard E. is certainly in a position to comment on this. The only
issue I see is that we're "using up" an instruction in the undefined
instruction space, meaning that it can't be used in some other magic way
by an OS. Linux presently uses an undefined instruction as a software
breakpoint. (I'm not sure why it does that instead of using an SVC
instruction?) But is there other stuff out there that might need this?
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 18:46 ` Mark Mitchell
@ 2010-09-09 18:49 ` Chris Lattner
2010-09-09 19:23 ` Mark Mitchell
0 siblings, 1 reply; 16+ messages in thread
From: Chris Lattner @ 2010-09-09 18:49 UTC (permalink / raw)
To: Mark Mitchell; +Cc: David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On Sep 9, 2010, at 11:28 AM, Mark Mitchell wrote:
> On 9/9/2010 11:20 AM, David Daney wrote:
>
>> I saw that, and I have no objections to that patch. But I was thinking
>> that this essentially augments the ABI. Could or should this be
>> coordinated with the maintainers of any ARM ABIs?
>
> Do other psABIs document how __builtin_trap is implemented?
>
> Richard E. is certainly in a position to comment on this. The only
> issue I see is that we're "using up" an instruction in the undefined
> instruction space, meaning that it can't be used in some other magic way
> by an OS. Linux presently uses an undefined instruction as a software
> breakpoint. (I'm not sure why it does that instead of using an SVC
> instruction?) But is there other stuff out there that might need this?
FWIW, the LLVM ARM backend compiles __builtin_trap into "trap" (aka .word 0xe7ffdefe).
-Chris
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 18:49 ` Chris Lattner
@ 2010-09-09 19:23 ` Mark Mitchell
2010-09-09 21:59 ` Chris Lattner
0 siblings, 1 reply; 16+ messages in thread
From: Mark Mitchell @ 2010-09-09 19:23 UTC (permalink / raw)
To: Chris Lattner; +Cc: David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On 9/9/2010 11:34 AM, Chris Lattner wrote:
> FWIW, the LLVM ARM backend compiles __builtin_trap into "trap" (aka .word 0xe7ffdefe).
Is "trap" a standard pseudo-op? I didn't see it in either the ARM ARM
or in ARM's assembler manual, but that doesn't mean it isn't there.
ARM's assembler has an "UND" pseudo-op, which takes an argument to say
exactly which undefined instruction you want. From the documentation,
it looks like the default, if you don't specify an argument is 0xe7f000f0.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-08 23:18 ` Mark Mitchell
2010-09-09 18:34 ` David Daney
@ 2010-09-09 19:30 ` Daniel Jacobowitz
2010-09-09 21:25 ` Mark Mitchell
1 sibling, 1 reply; 16+ messages in thread
From: Daniel Jacobowitz @ 2010-09-09 19:30 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Mike Stump, gcc-patches, rearnshaw, paul
On Wed, Sep 08, 2010 at 04:01:53PM -0700, Mark Mitchell wrote:
> The instructions I chose are documented as such. That's why I wrote:
>
> ;; Generate an invalid instruction. The instructions chosen are
> ;; documented as permanently UNDEFINED, so we can rely on the fact
> ;; that no future version of the architecture will use them.
FWIW, it occurred to me (belatedly) that there's no harm in using the
same instruction that GDB uses, anyway. It would cause SIGTRAP rather
than SIGILL on Linux. But then, it's __builtin_*trap* ... :-)
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 19:30 ` Daniel Jacobowitz
@ 2010-09-09 21:25 ` Mark Mitchell
2010-09-09 21:49 ` Daniel Jacobowitz
0 siblings, 1 reply; 16+ messages in thread
From: Mark Mitchell @ 2010-09-09 21:25 UTC (permalink / raw)
To: Mike Stump, gcc-patches, rearnshaw, paul
On 9/9/2010 12:23 PM, Daniel Jacobowitz wrote:
>> ;; Generate an invalid instruction. The instructions chosen are
>> ;; documented as permanently UNDEFINED, so we can rely on the fact
>> ;; that no future version of the architecture will use them.
>
> FWIW, it occurred to me (belatedly) that there's no harm in using the
> same instruction that GDB uses, anyway. It would cause SIGTRAP rather
> than SIGILL on Linux. But then, it's __builtin_*trap* ... :-)
I certainly don't mind what bitpattern we use and am happy to make that
change if that's what the ARM maintainers think best.
But, would this cause gdbserver to report that the application had hit a
breakpoint? If so, that seems bad; GDB won't know about the breakpoint.
Also, FWIW, on x86 __builtin_trap causes SIGILL, and being consistent
seems useful.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 21:25 ` Mark Mitchell
@ 2010-09-09 21:49 ` Daniel Jacobowitz
0 siblings, 0 replies; 16+ messages in thread
From: Daniel Jacobowitz @ 2010-09-09 21:49 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Mike Stump, gcc-patches, rearnshaw, paul
On Thu, Sep 09, 2010 at 01:50:50PM -0700, Mark Mitchell wrote:
> But, would this cause gdbserver to report that the application had hit a
> breakpoint? If so, that seems bad; GDB won't know about the breakpoint.
> Also, FWIW, on x86 __builtin_trap causes SIGILL, and being consistent
> seems useful.
It works out; GDB knows how to handle SIGTRAPs that are not caused by
a breakpoint.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 19:23 ` Mark Mitchell
@ 2010-09-09 21:59 ` Chris Lattner
2010-09-09 22:27 ` Anton Korobeynikov
2010-09-10 10:13 ` Richard Earnshaw
0 siblings, 2 replies; 16+ messages in thread
From: Chris Lattner @ 2010-09-09 21:59 UTC (permalink / raw)
To: Mark Mitchell; +Cc: David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On Sep 9, 2010, at 11:44 AM, Mark Mitchell wrote:
> On 9/9/2010 11:34 AM, Chris Lattner wrote:
>
>> FWIW, the LLVM ARM backend compiles __builtin_trap into "trap" (aka .word 0xe7ffdefe).
>
> Is "trap" a standard pseudo-op? I didn't see it in either the ARM ARM
> or in ARM's assembler manual, but that doesn't mean it isn't there.
> ARM's assembler has an "UND" pseudo-op, which takes an argument to say
> exactly which undefined instruction you want. From the documentation,
> it looks like the default, if you don't specify an argument is 0xe7f000f0.
Specifically, the LLVM backend emits:
_t: @ @t
.long 0xe7ffdefe @ trap
So no, I don't think that trap is a standard mnemonic. I have a vague memory of ARM not having an official trap instruction, but then retroactively deciding that some invalid encodings would never be defined.
-Chris
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 21:59 ` Chris Lattner
@ 2010-09-09 22:27 ` Anton Korobeynikov
2010-09-10 10:13 ` Richard Earnshaw
1 sibling, 0 replies; 16+ messages in thread
From: Anton Korobeynikov @ 2010-09-09 22:27 UTC (permalink / raw)
To: Chris Lattner
Cc: Mark Mitchell, David Daney, Mike Stump, gcc-patches, rearnshaw, paul
> Specifically, the LLVM backend emits:
>
> _t: @ @t
> .long 0xe7ffdefe @ trap
>
>
> So no, I don't think that trap is a standard mnemonic.
iirc "trap" is supported as a separate mnemonic in darwin as. gas does
not support it, thus we emit .word / .long here
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-09 21:59 ` Chris Lattner
2010-09-09 22:27 ` Anton Korobeynikov
@ 2010-09-10 10:13 ` Richard Earnshaw
2010-09-10 13:12 ` Mikael Pettersson
2010-09-10 14:34 ` Mark Mitchell
1 sibling, 2 replies; 16+ messages in thread
From: Richard Earnshaw @ 2010-09-10 10:13 UTC (permalink / raw)
To: Chris Lattner
Cc: Mark Mitchell, David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On Thu, 2010-09-09 at 14:20 -0700, Chris Lattner wrote:
> On Sep 9, 2010, at 11:44 AM, Mark Mitchell wrote:
>
> > On 9/9/2010 11:34 AM, Chris Lattner wrote:
> >
> >> FWIW, the LLVM ARM backend compiles __builtin_trap into "trap" (aka .word 0xe7ffdefe).
> >
> > Is "trap" a standard pseudo-op? I didn't see it in either the ARM ARM
> > or in ARM's assembler manual, but that doesn't mean it isn't there.
> > ARM's assembler has an "UND" pseudo-op, which takes an argument to say
> > exactly which undefined instruction you want. From the documentation,
> > it looks like the default, if you don't specify an argument is 0xe7f000f0.
>
> Specifically, the LLVM backend emits:
>
> _t: @ @t
> .long 0xe7ffdefe @ trap
>
>
> So no, I don't think that trap is a standard mnemonic. I have a vague memory of ARM not having an official trap instruction, but then retroactively deciding that some invalid encodings would never be defined.
>
> -Chris
You shouldn't use ".long" for instructions, use ".inst". ".long"
implies a word of data while ".inst" implies an instruction: in
big-endian mode the difference is significant.
R.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-10 10:13 ` Richard Earnshaw
@ 2010-09-10 13:12 ` Mikael Pettersson
2010-09-10 14:34 ` Mark Mitchell
1 sibling, 0 replies; 16+ messages in thread
From: Mikael Pettersson @ 2010-09-10 13:12 UTC (permalink / raw)
To: Richard Earnshaw
Cc: Chris Lattner, Mark Mitchell, David Daney, Mike Stump,
gcc-patches, rearnshaw, paul
Richard Earnshaw writes:
>
> On Thu, 2010-09-09 at 14:20 -0700, Chris Lattner wrote:
> > On Sep 9, 2010, at 11:44 AM, Mark Mitchell wrote:
> >
> > > On 9/9/2010 11:34 AM, Chris Lattner wrote:
> > >
> > >> FWIW, the LLVM ARM backend compiles __builtin_trap into "trap" (aka .word 0xe7ffdefe).
> > >
> > > Is "trap" a standard pseudo-op? I didn't see it in either the ARM ARM
> > > or in ARM's assembler manual, but that doesn't mean it isn't there.
> > > ARM's assembler has an "UND" pseudo-op, which takes an argument to say
> > > exactly which undefined instruction you want. From the documentation,
> > > it looks like the default, if you don't specify an argument is 0xe7f000f0.
> >
> > Specifically, the LLVM backend emits:
> >
> > _t: @ @t
> > .long 0xe7ffdefe @ trap
> >
> >
> > So no, I don't think that trap is a standard mnemonic. I have a vague memory of ARM not having an official trap instruction, but then retroactively deciding that some invalid encodings would never be defined.
> >
> > -Chris
>
> You shouldn't use ".long" for instructions, use ".inst". ".long"
> implies a word of data while ".inst" implies an instruction: in
> big-endian mode the difference is significant.
It also affects objdump, which in recent binutils won't disassemble
code in .text entered with pseudo-ops like .long or .word. ".inst" works.
/Mikael
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-10 10:13 ` Richard Earnshaw
2010-09-10 13:12 ` Mikael Pettersson
@ 2010-09-10 14:34 ` Mark Mitchell
2010-09-28 18:07 ` Mark Mitchell
1 sibling, 1 reply; 16+ messages in thread
From: Mark Mitchell @ 2010-09-10 14:34 UTC (permalink / raw)
To: Richard Earnshaw
Cc: Chris Lattner, David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On 9/10/2010 2:45 AM, Richard Earnshaw wrote:
> You shouldn't use ".long" for instructions, use ".inst". ".long"
> implies a word of data while ".inst" implies an instruction: in
> big-endian mode the difference is significant.
Just for avoidance of doubt, my patch doesn't use ".long"; it uses
".inst". May I apply it (possibly with some change to the choice of
constants) or is there something else that needs doing?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFA: ARM: Implement __builtin_trap
2010-09-10 14:34 ` Mark Mitchell
@ 2010-09-28 18:07 ` Mark Mitchell
0 siblings, 0 replies; 16+ messages in thread
From: Mark Mitchell @ 2010-09-28 18:07 UTC (permalink / raw)
To: Richard Earnshaw
Cc: Chris Lattner, David Daney, Mike Stump, gcc-patches, rearnshaw, paul
On 9/10/2010 6:55 AM, Mark Mitchell wrote:
>> You shouldn't use ".long" for instructions, use ".inst". ".long"
>> implies a word of data while ".inst" implies an instruction: in
>> big-endian mode the difference is significant.
>
> Just for avoidance of doubt, my patch doesn't use ".long"; it uses
> ".inst". May I apply it (possibly with some change to the choice of
> constants) or is there something else that needs doing?
Ping.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2010-09-28 14:59 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-08 6:10 RFA: ARM: Implement __builtin_trap Mark Mitchell
2010-09-08 23:05 ` Mike Stump
2010-09-08 23:18 ` Mark Mitchell
2010-09-09 18:34 ` David Daney
2010-09-09 18:46 ` Mark Mitchell
2010-09-09 18:49 ` Chris Lattner
2010-09-09 19:23 ` Mark Mitchell
2010-09-09 21:59 ` Chris Lattner
2010-09-09 22:27 ` Anton Korobeynikov
2010-09-10 10:13 ` Richard Earnshaw
2010-09-10 13:12 ` Mikael Pettersson
2010-09-10 14:34 ` Mark Mitchell
2010-09-28 18:07 ` Mark Mitchell
2010-09-09 19:30 ` Daniel Jacobowitz
2010-09-09 21:25 ` Mark Mitchell
2010-09-09 21:49 ` Daniel Jacobowitz
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).