[PATCH] D79672: [COFF] Move type merging to TpiSource::mergeDebugT virtual method

[Leonardo Santagada via Phabricator via llvm-commits]

santagada added inline comments.


================
Comment at: lld/COFF/DebugTypes.cpp:172
+  debugH = debugH.drop_front(sizeof(object::debug_h_header));
+  return header->Magic == COFF::DEBUG_HASHES_SECTION_MAGIC &&
+         header->Version == 0 &&
----------------
rnk wrote:
> aganea wrote:
> > I recall @santagada saying that linking `.debug$H` .OBJs with MSVC link.exe would fail. While browsing the microsoft-pdb repo, I was under the impression at one point that this 'Magic' field is actually a size of some sort to read more data. If link.exe treats it as a size, it would certainly fail in some way or another. This is unrelated to this patch, but it'd be good to clarify that situation.
> I have some vague recollection that things went like this:
> - LLVM added .debug$H. I wanted to ensure that it was compatible with link.exe, but I cannot confirm that this was tested thoroughly.
> - After switching Chromium to LLD, we enabled .debug$H in Chromium
> - Somebody was using link.exe to link Chromium, ran into a problem, they reported it to Microsoft, Yong Kang fixed it on the MSVC side by ignoring .debug$H
> 
> So I think the current state is that everything works, but @santagada probably did see some transient incompatibility.
We were using until very recently the 2015 link.exe because all the newer ones generate problems to debug when fast linking. Ms fixed those on 2019 .4 release so I can try again.

Still we are so close to moving away from link.exe completely. But thanks for the info


================
Comment at: lld/COFF/PDB.cpp:950
+
+  if (source->kind == TpiSource::PDB)
+    return; // No symbols in TypeServer PDBs
----------------
rnk wrote:
> aganea wrote:
> > I was wondering if we could pre-link some libraries to speed-up linking of rarely modified projects. We're building lots of external/third-party libraries compiled from source, because we want to enforce the same settings as the rest of the gamecode (for options like /MT or -flto=thin). However they are cached and very rarely compiled. But we'd still pay the cost to merge symbols and types at link-time.
> > Maybe each library (or each group of libraries) could come with a /Zi-style .PDB which LLD would use instead of the library's .OBJs. If that ever happens, we'd need to merge symbols here as well.
> True.
What I would like is to generate static libraries that are more than just a tar of obj, but actually have a merged type and possibly symbol tables. That would make linking much faster as you can distribute those libs and reuse most of them. Ar files have a place for these, maybe we could put a empty .obj with a specific name on a .lib and read from there when available?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79672/new/

https://reviews.llvm.org/D79672