Bug 89487
Summary: | ljmp *%eax can't be created | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Gregg Mattinson <grmattin> |
Component: | binutils | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-04-24 15:32:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gregg Mattinson
2003-04-23 13:54:11 UTC
This has nothing to do with gcc. It is gas which refuses to assemble it. Now, although it is possible to create .byte 0xff, 0xe8 instruction by hand, I'd like to know what do you expect the instruction to do and whether any CPU actually implements it (and how). You certainly cannot fit a 48 bit destination address into 32 bit register, if you want to jump to the 48 bit address pointed by %eax register, the insn is ljmp *(%eax) (which is 0xff 0x28). Looking e.g. at the bochs IA-32 emulator, 0xff 0xe8 insn generates an invalid insn exception. Thanks for pointing out the correct instruction I wanted. I did not notice the small difference between the two. I have changed my code to use ljmp *(%eax) and that appears to work the same as my old 0xFF 0xE8 hack. I am running my code in VMware Workstation 3.2.0, so I guess the bug is really in their code, because they implemented the 0xFF 0xE8 instruction by mistake. |