shortcut to address space map
more adjustments to shortcuts
allow null AddrSpace pointer in raw baselist
holes in the space indices
almost working
GT-2873 decompiler, other, and overlays
GT-2873 added OTHER space to java sleigh compiler, fixed decompiler
exception
isOtherSpace method
isOtherSpace java, addressing code review comments
GT-2873 added null check in decompiler reset
GT-2873 code review changes
Read and write space_other tag in SLA files
Version number for .sla file
GT-2873 fixups after merge
GT-2873 renamed Sparc registers: OTHER->OTHERWIN, WINWSTATE->WSTATE
GT-2873 added option in AddressInput to control OTHER space visibility
GT-2873 OTHER space now global
GT-2873 fixing comments refering to decompiler code in BasicCompilerSpec
The SAHF/LAHF instructions date from the 32bit x86 days, and where initially
marked as obsolete in the AMD 64bit spec. All processors have the requisite
logic, as they are backwards compatible in 32bit mode.
The original 64bit CPUs from Intel and AMD would raise #UD for these
instructions, per the AMD64 spec.
However, they were were sufficiently critical for software emulators that the
instructions were "reintroduced" into the AMD64 spec, with a new CPUID bit
indicating that the they were now usable in 64bit mode.
In practice, every 64bit capable processor since 2005 has supported them.
Fixes#837
R_X86_64_GOT32 and R_X86_64_PLT32 are 32-bit entries but the ELF
RelocationHandler would rewrite longs (64-bit), overwriting the
following bytes with the 64-bit sign-extension thus overwriting
the next instructions.
Rewrite int (32-bit) instead and properly relocate entries using
addend and offset fields as defined in AMD64 ABI.
Signed-off-by: Andy Roulin <andy.roulin@gmail.com>
Several x86_64 instructions were not sign extending the imm32 to
64-bits for the 64-bit mode instruction: ADD, AND, CMD, and SUB,
while: ADC, MOV, and TEST were correct
* `CC` and `CD 03` are different instructions, but previously disassembled to
`INT 3` and `INT 0x3` respectively.
The proper mnemonic for the former is `INT3` (no space), while the latter
is a byte sequence only seen in tests and when trying to exploit emulator
bugs. Switch `CC` to use its documented mnemonic, which makes it easier to
distinguish.
* `INT1`, also commonly known as `ICEBP` (In Circuit Emulator Break-Point)
has existed since the 486 processor, and was finally documented by Intel
following the fallout from CVE-2018-8897. Model it after `INT3`.
* It is unclear why there is a specialisation for `:INT n29`, because vector
29 is `#VC` in newer AMD CPUs, and can't be invoked using the `INT $29`
instruction anyway.
The byte sequence `CC 1D` always gets disassembled using `:INT imm8`, which
suggests that SLEIGH has noticed the redundancy and folded the decode
rules. Drop the specialisation.
Fixes#514
x86 16-bit in IDA Pro >= 7.0 and probably earlier uses the metapc processor type and not any of those listed anymore. I am not sure how many others should also be included but probably all of them. The bit size is the primary selection, not the processor type anymore so although metapc is confirmed, perhaps the following should also be added as they are under 32-bit:
<external_name tool="IDA-PRO" name="80686p"/>
<external_name tool="IDA-PRO" name="k62"/>
<external_name tool="IDA-PRO" name="p2"/>
<external_name tool="IDA-PRO" name="p3"/>
<external_name tool="IDA-PRO" name="athlon"/>
<external_name tool="IDA-PRO" name="p4"/>
Though this is certainly a legacy IDA 5.x and maybe 6.x issue mainly. AFAIK, all the >= 7.0 IDA versions use metapc for all x86. Specific processors were any early feature that was consolidated there.
According to Intel manual, the AAM instruction has a MOD, not an AND. Likely a typo. More, (AF == 1) added instead of AF (but I think it's pretty much the same)
+ bonus typo fix
removing a line that appears to be superfluous. also, fix indentation.
unfortunately, i have *not* tested this, as i noticed this apparent extra line during a visual inspection. i don't have a build environment currently configured.
