For x86, kedr stole the kernel’s x86 instruction decoding code, along with various header and support files. This was meant to allow kedr to keep working even if the kernel’s instruction decoding API changed (which it has a little bit, since kedr took these files in 2010 and hasn’t updated them since). Kent took arm64’s instruction decoding logic (insn.c), but didn’t take the header files (on x86 there’s only 3-4 files, but on arm64 the header dependencies are a little more intricate so it’s more than that… probably in double digits). This means that kedr will use the system headers, which may have a different API, which caused various issues for kedr back in 2012. Since we’re using the same kernel version as the code for the arm64 instruction decoding that we took (for now), this shouldn’t be a problem (since it clearly works), but it’s not ideal.
It would probably also be a good idea to update the x86 instruction decoding in kedr at some point… there have been a fair amount of improvements + bug fixes since 2010, but it would mean pulling in some new files and potentially messing with some kedr code
For x86, kedr stole the kernel’s x86 instruction decoding code, along with various header and support files. This was meant to allow kedr to keep working even if the kernel’s instruction decoding API changed (which it has a little bit, since kedr took these files in 2010 and hasn’t updated them since). Kent took arm64’s instruction decoding logic (insn.c), but didn’t take the header files (on x86 there’s only 3-4 files, but on arm64 the header dependencies are a little more intricate so it’s more than that… probably in double digits). This means that kedr will use the system headers, which may have a different API, which caused various issues for kedr back in 2012. Since we’re using the same kernel version as the code for the arm64 instruction decoding that we took (for now), this shouldn’t be a problem (since it clearly works), but it’s not ideal.
It would probably also be a good idea to update the x86 instruction decoding in kedr at some point… there have been a fair amount of improvements + bug fixes since 2010, but it would mean pulling in some new files and potentially messing with some kedr code