This teaches yaml2obj and obj2yaml to be able to dump and generate the experimental COFF .debug$H section. Emitting this section from clang and using it in LLD is still unimplemented, as I want to get all the proper testing infrastructure in place first.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp | ||
---|---|---|
51–54 ↗ | (On Diff #125559) | Seeing as how nothing stops MSFT from using the debug$H section for something of their own invention, maybe we should have a magic four byte sequence at the section start to identify that we made it? |
llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp | ||
---|---|---|
51–54 ↗ | (On Diff #125559) | Once we have this all working, I plan to send a modified copy of the PE/COFF spec to MS and see about getting it officially in the spec. That said, wouldn't your concern already be addressed by the 16-bit Version field? |
llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp | ||
---|---|---|
51–54 ↗ | (On Diff #125559) | If Microsoft adds the same section with a different meaning, and if they decide to add a version field at the beginning of the section (it's not an unreasonable assumption), they would conflict, no? |
llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp | ||
---|---|---|
51–54 ↗ | (On Diff #125559) | If they add the same section with different meaning then it doesn't matter what we add to this section, because it could still conflict. If we're going to use the same section name at all, we have to at least agree on how to parse the header. So if they add the same section name with different meaning, and we can't agree on a format that doesn't lead to a conflict, we would probably just have to change the section name entirely. I'm not really that opposed to adding another 4-byte magic field to the beginning, but it seems unnecessary since we already have 4 bytes at the beginning which we can treat as "magic". |
llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp | ||
---|---|---|
51–54 ↗ | (On Diff #125559) | I mildly prefer the idea of adding the magic number. It's not a strong preference. If you have that one, when Microsoft starts using .debug$H in a different meaning, we can check whether a section starts with the magic number or not and then dispatch. Version number 0 wouldn't work as a magic number as it is too common, but for example 0x16E9CB37 (I made up this number from $RANDOM) is very unlikely to conflict with what Microsoft would add to the beginning of the section. |
I added an extra 4-byte field at the beginning of our stream which expects to be set to 0x133C9C5.