[PATCH] D40842: [ObjectYAML] Update obj2yaml and yaml2obj for .debug$H section

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added inline comments.


================
Comment at: llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp:51-54
+  BinaryStreamReader Reader(DebugT, llvm::support::little);
+  DebugHSection DHS;
+  cantFail(Reader.readInteger(DHS.Version));
+  cantFail(Reader.readInteger(DHS.HashAlgorithm));
----------------
zturner wrote:
> ruiu wrote:
> > zturner wrote:
> > > majnemer wrote:
> > > > 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?
> > > 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?
> > 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?
> 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".
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.


https://reviews.llvm.org/D40842