Before this commit the unique identifier for an executable file or object file was the build id. As the GNU's build ID might not be present, we fall back to the sha256 hash of the .text section. This works fine but takes quite a bit of space as we refer to it in every mapping.
By using a 64 bit id derived from the first 8 bytes of the sha256 hash of the code, we can save a good amount of memory, make comparisons and hashings of these IDs faster, and helps simplify the code. For example, there's no need for a separate ID in the native unwind state. There might be a bit more CPU and IO needed to get the hash, but this might be something we can cache in the future.
This is also useful for future profile formats that require unique 64 bit IDs for object files.
This commit also fixes other minor things, such as using the lower hexadecimal representation.
Tagging you, @gmarler, because this is changes load-bearing parts of the code, let me know if you spot any issues and I will be happy to take a look 😀 .
Before this commit the unique identifier for an executable file or object file was the build id. As the GNU's build ID might not be present, we fall back to the sha256 hash of the .text section. This works fine but takes quite a bit of space as we refer to it in every mapping.
By using a 64 bit id derived from the first 8 bytes of the sha256 hash of the code, we can save a good amount of memory, make comparisons and hashings of these IDs faster, and helps simplify the code. For example, there's no need for a separate ID in the native unwind state. There might be a bit more CPU and IO needed to get the hash, but this might be something we can cache in the future.
This is also useful for future profile formats that require unique 64 bit IDs for object files.
This commit also fixes other minor things, such as using the lower hexadecimal representation.
Test Plan
Lots of manual tests, everything seems good.