I compiled the processor module and copied it to IDA Pro 8.3, then loaded a QSDP6 elf binary and then:

Oops, IDA has almost crashed! (signum=11)
Unloading IDP module /opt/idapro-8.3/procs/hexagon64.so...

I know this is very little information, if you can supply me with hints how to give you the details necessary to fix it I will add this here :)

when the loader comes to dissamble the following instruction, the data reference of imm32 (unk_B01E19EC) is missed. Would you have a look at this?
r0 = memw(##unk_B01E19EC) }

Although the core doesn't support unaligned mem accesses, there are many binaries containing "packed" unaligned 32-bit values (accessed as val = ptr[0] | (ptr[1]<<8) | (ptr[2]<<16) | (ptr[3]<<24)). PR_ALIGN flag prohibits converting such values to dwords/offsets. It looks safe to remove PR_ALIGN, code alignment is enforced in ana() already.

hi,
Recently I've been looking for info about Hexagon HMX. It looks like there is rare info for this extension. Thank you for your repo and I am wondering where did you find those HMX instructions?

I have tried to use the windows pre compiled - hexagon-ida75-v3.0.7z - version.
After loading Elf or even binary file ... IDA Segment View crashes ...
Any idea ?
I am using - IDA Version 7.5.201028 Windows x64 (32-bit address size)

A simple test.

[ming@PC test]$ cat test.c
extern int one();

int two() 
{
  return one() + 1;
}
[ming@PC test]$ /usr/bin/llvm-objdump -d test.o

test.o:	file format elf32-hexagon

Disassembly of section .text:

00000000 <two>:
       0:	00 c0 9d a0	a09dc000 { 	allocframe(#0) } 
       4:	00 c0 00 5a	5a00c000 { 	call 0x4 } 
       8:	20 c0 00 b0	b000c020 { 	r0 = add(r0,#1) } 
       c:	1e c0 1e 96	961ec01e { 	dealloc_return } 
[ming@PC test]$ /usr/bin/llvm-objdump -x test.o

test.o:	file format elf32-hexagon
architecture: hexagon
start address: 0x00000000

Program Header:

Dynamic Section:

Sections:
Idx Name            Size     VMA      Type
  0                 00000000 00000000 
  1 .strtab         00000052 00000000 
  2 .text           00000010 00000000 TEXT
  3 .rela.text      0000000c 00000000 
  4 .comment        00000016 00000000 
  5 .note.GNU-stack 00000000 00000000 
  6 .llvm_addrsig   00000001 00000000 
  7 .symtab         00000040 00000000 

SYMBOL TABLE:
00000000 l    df *ABS*	00000000 test.c
00000000 g     F .text	00000010 two
00000000         *UND*	00000000 one

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE                     VALUE
00000004 R_HEX_B22_PCREL          one

It is displaying "call 0x4" in IDA disassembly, how can I make it "call one".
I checked the source code but I don't know what to do.
The arm/aarch64 target is fine.

Hexagon V73 is out:
https://developer.qualcomm.com/qfile/70668/80-n2040-53_aa_prm_v73.pdf
https://developer.qualcomm.com/qfile/70666/80-n2040-54_aa_v73_hvx_prm.pdf

Qualcomm added some system instructions in November (and before).
See: https://github.com/llvm/llvm-project/commits/bd91cf8d83a9c352a02ea1b66095ef53362e027c

They should be added (if not already done).

pls publish the release for ida 7.7 and ida64 7.7:)
tks :))

Hi. I compiled the module with IDA SDK 7.7, but I get an assertion error when trying to load a file. It is in ana.cpp, row 146: assert( op->type == o_reg ).
If I ignore it, It loads fine.

A duplex can be reported to IDA as two separate insns:

• report the first half as an insn of size 2
• ana() will be called at ea misaligned by 2 for the second half
• check for such misaligns && for the aligned word being a duplex, decode the second half (from a full aligned word) and report it as another insn of size 2
  Opcode bytes display would be mixed up of course (as the duplex encoding is not split nicely as 16:16), but we'd get two separate insns, each with it's own ops etc, creating instruc_t table would be possible too (no more need to represent each possible duplex combination as a separate insn).

The indices assigned to the system registers differ from the programmers reference manual.

For example:
pmucfg is s53 in the manual but in

Also:
Some registers are not present at all or have different names:
In the manual s22 is register IAD,

Ubuntu 20.04.1 LTS
gcc version 9.3.0
GNU Make 4.2.1

make[2]: Entering directory '/home/ubuntu/Workspace/idasdk72/module/hexagon' g++ -m64 --shared -Wl,--no-undefined -o ../../bin/procs/hexagon.so obj/x64_linux_gcc_32/ana.o obj/x64_linux_gcc_32/emu.o obj/x64_linux_gcc_32/ins.o obj/x64_linux_gcc_32/out.o obj/x64_linux_gcc_32/reg.o obj/x64_linux_gcc_32/loader.o -L../../lib/x64_linux_gcc_32/ -lida -Wl,--build-id -Wl,--gc-sections -Wl,--warn-shared-textrel -Wl,-O1 -Wl,-Map,obj/x64_linux_gcc_32/hexagon.so.map -Wl,--version-script=../../module/exports.def -lrt -lpthread -lc /usr/bin/ld: obj/x64_linux_gcc_32/emu.o: in function jump_pattern_t::jump_pattern_t(switch_info_t*, char const (*) [4], int)':
/home/ubuntu/Workspace/idasdk72/module/hexagon/../../include/jumptable.hpp:517: undefined reference to hex_jump_pattern_t::s_depends' collect2: error: ld returned 1 exit status make[2]: *** [../../module.mak:49: ../../bin/procs/hexagon.so] Error 1 make[2]: Leaving directory '/home/ubuntu/Workspace/idasdk72/module/hexagon' make[1]: *** [makefile:57: hexagon] Error 2 make[1]: Leaving directory '/home/ubuntu/Workspace/idasdk72/module' make: *** [makefile:26: module] Error 2

The processor type 'QDSP6' is not included in the installed version of IDA...

but it only recognizes the binary AFTER copy this .so over.

So IDA is actually blocking this tool?

Hello
getting error "ph.reg_last_sreg, ph.reg_first_sreg are wrong" while loading.
sample file can provide in private.