WIP-minor ARM ELF tweaks #290
Conversation
…info (we only need the first one, and sometimes there is only one)
… described as LOC_POINTER, the call to makeCode didn't include any architecture context. this doesn't work for ARM when in Thumb mode. added "previous opcode" mode. also, rearranging "pointers" analysis module logging and error handling.
…us pointer naming. update unittests. also, renamed my new "reprLocation()" since it already exists. renamed to "reprLocEntry()"
| print seg[2] | ||
| vwdis(vw, seg[0], 10) | ||
|
|
||
| linux/i386/vdir: |
There was a problem hiding this comment.
It's starting to feel like we needs a notes directory (not a user facing docs directory, though we need that too) so we can store stuff like this in a more organized fashion.
There was a problem hiding this comment.
sounds good. what do you propose? these "take into account all the millions of combinations we need to deal with" problems are kinda annoying
There was a problem hiding this comment.
Honestly a more comprehensive writeup might belong in a docs directory (something I've been procrastinating on for a long time). Because looking at this below here with intermingled section output (there's also a couple exception print outs in there?) and opcodes, I could not tell you off the top of my head why it's all there.
So maybe not in this PR, but as part of a cleanup one, it might be good to get your thoughts on it down in some real docs.
…ms like performing ELF/PLT analysis to "predict" where functions are is more pain than it's worth, and the code is getting more and more complex to do so. either: we'll want to simply lay down opcodes using makeCode() and let the function analysis do the rest, or we may want to refactor the codebase for simplified maintenance. also, changing unittests to make failures more understandable.
… wrong, complete analysis.
…applies to this. the separation of analyzePLT() and analyzeFunction() is getting blurrier, as analyzePLT() appears to be requiring much more complex analysis to "get it right". going to try a couple things to see how we can reduce brittleness and complexity of the elfplt analysis module.
all unit tests seem to agree.
update unittest data for linux/arm/sh
…g up the consistency of the tests.
… of GOT entries was a bad idea. my unittests did that for him. <facepalm>
…n my machines) figured out.. (damn libc++1)
| print seg[2] | ||
| vwdis(vw, seg[0], 10) | ||
|
|
||
| linux/i386/vdir: |
There was a problem hiding this comment.
Honestly a more comprehensive writeup might belong in a docs directory (something I've been procrastinating on for a long time). Because looking at this below here with intermingled section output (there's also a couple exception print outs in there?) and opcodes, I could not tell you off the top of my head why it's all there.
So maybe not in this PR, but as part of a cleanup one, it might be good to get your thoughts on it down in some real docs.
|
|
||
| def debuginfosyms(self, vw, data, fname): | ||
| # we don't currently parse debugging symbols. | ||
| # while they are seldom in hard targets, this is a weakness we should correct. | ||
| pass | ||
| return 0,0 |
There was a problem hiding this comment.
That reminds me. I've got a dwarfinfo branch out still. I should go back and update that.
…getEndian() prep update to use reprLocation instead of the loctype number.
some documentation and a few things missed during the last melee