-
-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autodetect asm.cpu whenever possible #4196
base: dev
Are you sure you want to change the base?
Conversation
374bb57
to
0d4230d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this direction is correct. Once you finish it, please also add a test.
Sure, I'll do that. |
@valdaarhun do you have any progress on this? It would be nice to include it into the upcoming 0.7.0 release |
Hi. Yes, I have made some progress. There's not much left.
Got it. I should be able to finish the implementation soon. |
TODO:
|
@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. |
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.
Rename "read_arm_attributes_section()" to "read_arm_aeabi_section()". This function searches for the "TAG_FILE" sub-subsection.
Each tag's value is defined as a null-terminated string or a uleb128-encoded number. This info will be required while searching for "TAG_CPU_ARCH" and "Tag_CPU_ARCH_PROFILE" in the "ARM_TAG_FILE" sub-subsection.
* Read arm build attributes * Incorporate reviewed changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
@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. |
Your checklist for this pull request
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:
Test plan
Will think of one after finishing the implementation.
Closing issues
Fixes #3747