-
Notifications
You must be signed in to change notification settings - Fork 108
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
read: add support for DWP index sections #588
Conversation
Are "DWP index sections" documented somewhere? |
DWARF 5 documents them in 7.3.5 (DWARF Package Files). The GNU extension to DWARF 4 is documented at https://gcc.gnu.org/wiki/DebugFissionDWP. |
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.
I believe the handling of the DwoId/DebugTypeSignature to hash conversions has incorrect endian handling.
The docs (7.3.5.3 specifically) say "Define REP(X) to be the value of X interpreted as an unsigned 64-bit integer in the target byte order." As far as I can tell there's no allowance for cases where the target endianness and the program endianness are different like there is elsewhere in gimli.
I don't understand what you mean. |
They're parsed in the target byte order, yes, but if I'm reading the spec correctly the hash must also be computed with those 64 bit integers in the target byte order, which doesn't happen here. |
(And that inherently makes some amount of sense. The on disk hashes were computed on the target machine and our computation needs to match that exactly in order to produce the same hash.) |
Right, the on disk hash and the on disk DwoId/TypeSignature are both computed using the target machine byte order. But we read both of those using the target byte order. The hash operations don't care about endianness. Once you have a 64-bit integer, a right shift 32 means the same regardless of the original byte order. That's the point of converting it to a 64-bit integer instead of using a byte array. |
Ah, hrm, maybe I'm misunderstanding what "interpreted in the target byte order" means then. |
"Given an 8-byte compilation unit ID or type signature X, an entry in the hash table is located as follows:
My interpretation is that if you start with an 8-byte compilation unit ID or type signature X (which is a |
fwiw nothing else raised my eye beyond that potential endianness issue. |
r? @khuey (since this builds on your DWO work)