Autodetect asm.cpu whenever possible

[valdaarhun]

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

get_cpu_arm() scans through the ".ARM.attributes" section of the ELF file to find the "aeabi" subsection. This subsection contains general build attributes that records data about the compatibility of the ELF file. The relevant tags in this subsection (eg: Tag_CPU_arch) can help determine asm.cpu.

References:

• https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst
• https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst

Test plan

Will think of one after finishing the implementation.

Closing issues

Fixes #3747

[XVilka]

Yes, this direction is correct. Once you finish it, please also add a test.

[valdaarhun]

Yes, this direction is correct. Once you finish it, please also add a test.

Sure, I'll do that.

[XVilka]

@valdaarhun do you have any progress on this? It would be nice to include it into the upcoming 0.7.0 release

[valdaarhun]

@valdaarhun do you have any progress on this?

Hi. Yes, I have made some progress. There's not much left.

It would be nice to include it into the upcoming 0.7.0 release

Got it. I should be able to finish the implementation soon.

[valdaarhun]

TODO:

• Parse tags correctly in read_arm_build_attributes(). Some tags such as TAG_COMPATIBILITY have a few quirks but handling them should not be too hard.
• Testing

[XVilka]

@valdaarhun hi, have you had any progress on this PR?

[valdaarhun]

@valdaarhun hi, have you had any progress on this PR?

Hi. Sorry, I wasn't able to give much time to this last week. I do have some more commits to push. I'll push those for review. There's some more implementation left to do in the parser. I'll finish that up as well.

[XVilka]

It breaks DWARF profile loading in some of the tests in its current state:

[XX] db/cmd/dwarf "ARM types"
RZ_NOPLUGINS=1 /usr/bin/rizin -escr.utf8=0 -escr.color=0 -escr.interactive=0 -eflirt.sigdb.load.system=false -eflirt.sigdb.load.home=false -N -Qc 'aaa
afvl @ dbg.main
pdf @ dbg.new_some
aaa
' bins/elf/test_app2/test_app2.elf
-- stdout
--- expected
+++ actual
@@ -4,15 +4,15 @@
 var int32_t var_2ch @ stack - 0x2c
 var int32_t var_1ch @ stack - 0x1c
 var some_t *s @ stack - 0x1a
-arg int argc @ r0
-arg char **argv @ r1
-var struct Some *gg @ r2
+arg int argc @ reg0
+arg char **argv @ reg1
+var struct Some *gg @ reg2
 var float a @ ...
 var float b @ ...
 var double c @ ...
             ; CALL XREFS from dbg.main @ 0x817c, 0x8184
 / some_t * new_some()
-|           ; var struct Some *n @ r4
+|           ; var struct Some *n @ reg4

[valdaarhun]

It breaks DWARF profile loading in some of the tests in its current state:

[XX] db/cmd/dwarf "ARM types"
RZ_NOPLUGINS=1 /usr/bin/rizin -escr.utf8=0 -escr.color=0 -escr.interactive=0 -eflirt.sigdb.load.system=false -eflirt.sigdb.load.home=false -N -Qc 'aaa
afvl @ dbg.main
pdf @ dbg.new_some
aaa
' bins/elf/test_app2/test_app2.elf
-- stdout
--- expected
+++ actual
@@ -4,15 +4,15 @@
 var int32_t var_2ch @ stack - 0x2c
 var int32_t var_1ch @ stack - 0x1c
 var some_t *s @ stack - 0x1a
-arg int argc @ r0
-arg char **argv @ r1
-var struct Some *gg @ r2
+arg int argc @ reg0
+arg char **argv @ reg1
+var struct Some *gg @ reg2
 var float a @ ...
 var float b @ ...
 var double c @ ...
             ; CALL XREFS from dbg.main @ 0x817c, 0x8184
 / some_t * new_some()
-|           ; var struct Some *n @ r4
+|           ; var struct Some *n @ reg4

I am not sure why this is happening. I'll investigate this further.

[XVilka]

@wargio, we will need the same approach for MIPS files. Apparently, corresponding ELF files contain more precise information about the CPU used than we currently process.