RzIL v810 support

[imbillow]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've documented or updated the documentation of every function and struct this PR changes. If not so I've explained why.
• I've added tests that prove my fix is effective or that my feature works (if possible)
• I've updated the rizin book with the relevant information (if needed)

Detailed description

...

Test plan

...

Closing issues

...

[XVilka]

As for tracetesting, I wasn't able to find any good open source V810 emulator. If there is none, we can skip this test. Maybe can craft more convoluted "emulateme" test instead?

UPDATE: There is MAME though: https://github.com/mamedev/mame/tree/master/src/devices/cpu/v810

[XVilka]

We also lack any ELF and analysis tests for this architecture. Might be a good idea also to check if DWARF works too.

[wargio]

why these?

[imbillow]

Since several instructions need to read and write SR registers with index, these reversed registers need to be at the location.

[imbillow]

the v810 binary: rizinorg/rizin-testbins#138

[XVilka]

The RzIL part looks fine. Could you please extend also ELF and DWARF loaders to load debug information for these ELF files?
I wonder if you can also compile that float_ex1.c with and without DWARF to check the debuginfo information loading and the analysis precision.

[imbillow]

The RzIL part looks fine. Could you please extend also ELF and DWARF loaders to load debug information for these ELF files?

I wonder if you can also compile that float_ex1.c with and without DWARF to check the debuginfo information loading and the analysis precision.

Is it going in this PR?

[XVilka]

@imbillow ELF architecture detection should be just a couple of lines and can be done in the same PR; see: 0440ab4

The rest of my suggestions are indeed better to be done in a separate PR.

[imbillow]

@imbillow ELF architecture detection should be just a couple of lines and can be done in the same PR; see: 0440ab4

The rest of my suggestions are indeed better to be done in a separate PR.

This v810-gcc 4.9.4 looks buggy and can't generate DWARF.

./v810-gcc/bin/v810-gcc -gdwarf-4 -std=c99 emulateme.c -o emulateme.v810
emulateme.c: In function 'decrypt':
emulateme.c:26:1: internal compiler error: in create_cie_data, at dwarf2cfi.c:2880
 }
 ^

emulateme.c:26:1: internal compiler error: Segmentation fault
v810-gcc: internal compiler error: Segmentation fault (program cc1)
fish: Job 1, './v810-gcc/bin/v810-gcc -gdwa...' terminated by signal SIGSEGV (Address boundary error)

[XVilka]

@imbillow ELF architecture detection should be just a couple of lines and can be done in the same PR; see: 0440ab4
The rest of my suggestions are indeed better to be done in a separate PR.

This v810-gcc 4.9.4 looks buggy and can't generate DWARF.

./v810-gcc/bin/v810-gcc -gdwarf-4 -std=c99 emulateme.c -o emulateme.v810
emulateme.c: In function 'decrypt':
emulateme.c:26:1: internal compiler error: in create_cie_data, at dwarf2cfi.c:2880
 }
 ^

emulateme.c:26:1: internal compiler error: Segmentation fault
v810-gcc: internal compiler error: Segmentation fault (program cc1)
fish: Job 1, './v810-gcc/bin/v810-gcc -gdwa...' terminated by signal SIGSEGV (Address boundary error)

Ok, ignore my suggestion about DWARF and just add ELF detection and analysis test (functions/variables/etc) in a separate PR as we agreed.