This is an archive of the discontinued LLVM Phabricator instance.

[X86] Added INT1 instruction and fixed register usage.
AcceptedPublic

Authored by cray on Jan 27 2017, 2:57 PM.

Details

Reviewers
craig.topper
Summary

Documentation on INT1 can be found here:
http://www.rcollins.org/secrets/opcodes/ICEBP.html

Diff Detail

Event Timeline

cray created this revision.Jan 27 2017, 2:57 PM
cray retitled this revision from [X86] Added INT1 instruction and fixxed register usage. to [X86] Added INT1 instruction and fixed register usage..Jan 27 2017, 2:59 PM
cray set the repository for this revision to rL LLVM.
craig.topper edited edge metadata.Jan 27 2017, 4:49 PM

I'd prefer not to use an undocumented instruction in codegen unless gcc or other major compiler does. Do you know if they do?

cray added a comment.EditedJan 27 2017, 5:10 PM

I will work on searching through our bug reports to try and figure out what generated the undocumented instruction. We have been using this patch since llvm 3.2, so I can't remember what generated this instruction.

I don't agree with it being generated by the compiler in a normal circumstance either, but i would say that it should be available to the assembler, or an intrinsic.

cray added a comment.Jan 29 2017, 12:11 PM

I can remove the int1 from the intrinsic. No other compiler will generate this, and it is normally generated by certain debuggers. I was able to find out that this was documented in the AMD opcode map.

I also found out that this instruction is supported by intel XED. https://github.com/intelxed/xed/blob/eb45a282de284ec2574e2b54460b37b7e587996c/datafiles/xed-isa.txt#L8238

cray added a comment.Jan 29 2017, 5:28 PM

I just found out NASM generates this opcode for both x86 and x64. In the manual it refers to it as icebp, and says that it accepts the alias int1. I was thinking about renaming this instruction to icebp so that it is not generated by a typo in assembly. Also, the lit tests seem to match int $1 when the check line is int1

cray updated this revision to Diff 86295.Jan 30 2017, 8:51 AM

Changed the mnemonic for INT1 to icebp, and removed it from codegen.

craig.topper added inline comments.Jan 30 2017, 5:20 PM
lib/Target/X86/X86InstrSystem.td
35

The instructions don't really modify ESP or EFLAGS. I would expect them to be restored when the interrupt handler returned. So from the perspective of the code with the INT insturction they aren't changed.

cray added inline comments.Jan 30 2017, 7:29 PM
lib/Target/X86/X86InstrSystem.td
35

The flags are pushed onto the stack, and if the INT causes an exception they will not be popped from the stack when the exception handler is called.
I can put together an example of this if you would like.

cray added inline comments.Jan 30 2017, 7:58 PM
lib/Target/X86/X86InstrSystem.td
35

I explained that poorly in my previous comment. The following is taken from the intel manual:

Flags Affected
The EFLAGS register is pushed onto the stack. The IF, TF, NT, AC, RF, and VM flags may be cleared, depending on
the mode of operation of the processor when the INT instruction is executed (see the “Operation” section). If the
interrupt uses a task gate, any flags may be set or cleared, controlled by the EFLAGS image in the new task’s TSS.

Also, in the case of windows SEH, the stack should be unwound, but the flags will not be restored.

This revision is now accepted and ready to land.Feb 3 2017, 6:07 PM
test/MC/X86/x86-32.s