similar to: Missing data on PDB's generated by lld

No, we use msvc cl.exe as a compiler generating C7 debug information (here is more or less our compiler options regarding optimization/debugability): /Z7 /GL- /bigobj /Zo /utf-8 /arch:AVX /std:c++14 /Zc:inline /Zc:ternary /Zc:rvalueCast /Zc:strictStrings /O2 /MD In this list the only weird one is /bigobj, my main fear is that we might get to the limit of sections on an obj and then by adding the

On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> wrote: > Hi, > > No I didn't, I used cl.exe from the visual studio toolchain. What I'm > proposing is a tool for processing .obj files in COFF format, reading them > and generating the GHASH part. > > To make our build faster we use hundreds of unity build files (.cpp's with > a

Chrome is actually one of my exact benchmark cases. When building blink_core.dll and browser_tests.exe, i get anywhere from a 20-40% reduction in link time. We have some other optimizations in the pipeline but not upstream yet. My best time so far (including other optimizations not yet upstream) is 28s on blink_core.dll, compared to 110s with /debug On Sat, Jan 20, 2018 at 12:28 PM Leonardo

You probably don't want to go down the same route that clang goes through to write the object file. If you think yaml2coff is convoluted, the way clang does it will just give you a headache. There are multiple abstractions involved to account for different object file formats (ELF, COFF, MachO) and output formats (Assembly, binary file). At least with yaml2coff It's true that yaml2coff

On Fri, Jan 19, 2018 at 1:02 PM Leonardo Santagada <santagada at gmail.com> wrote: > On Fri, Jan 19, 2018 at 9:44 PM, Zachary Turner <zturner at google.com> > wrote: > >> >> >> On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> >> wrote: >> >>> Hi, >>> >>> No I didn't, I used cl.exe

if we get to < 30s I think most users would prefer it to link.exe, just hopping there is still some more optimizations to get closer to ELF linking times (around 10-15s here). On Sat, Jan 20, 2018 at 9:50 PM, Zachary Turner <zturner at google.com> wrote: > Generally speaking a good rule of thumb is that /debug:ghash will be close > to or faster than /debug:fastlink, but with none

On Fri, Jan 19, 2018 at 9:44 PM, Zachary Turner <zturner at google.com> wrote: > > > On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> > wrote: > >> Hi, >> >> No I didn't, I used cl.exe from the visual studio toolchain. What I'm >> proposing is a tool for processing .obj files in COFF format, reading them

On Sat, Jan 20, 2018 at 9:05 PM, Zachary Turner <zturner at google.com> wrote: > You probably don't want to go down the same route that clang goes through > to write the object file. If you think yaml2coff is convoluted, the way > clang does it will just give you a headache. There are multiple > abstractions involved to account for different object file formats (ELF, >

I can totally see something like incremental linking with a simple padding between obj and a mapping file (which can also help with edit and continue, something we also would love to have). We have another developer doing the port to support clang-cl, but although most of our code also goes trough a version of clang, migrating the rest to clang-cl has been a fight. From what I heard the main

Here it is a minimal example, we do this so we don't have to import the whole windows api everywhere. https://gist.github.com/santagada/7977e929d31c629c4bf18ebb987f6be3 On Sun, Jan 21, 2018 at 2:31 AM, Zachary Turner <zturner at google.com> wrote: > Clang-cl maintains compatibility with msvc even in cases where it’s non > standards compliant (eg 2 phase name lookup), but we try

Generally speaking a good rule of thumb is that /debug:ghash will be close to or faster than /debug:fastlink, but with none of the penalties like slow debug time On Sat, Jan 20, 2018 at 12:44 PM Zachary Turner <zturner at google.com> wrote: > Chrome is actually one of my exact benchmark cases. When building > blink_core.dll and browser_tests.exe, i get anywhere from a 20-40% >

10-15s will be hard without true incremental linking. At some point that's going to be the only way to get any faster, but incremental linking is hard (putting it lightly), and since our full links are already really fast we think we can get reasonably close to link.exe incremental speeds with full links. But it's never enough and I will always want it to be faster, so you may see

Clang-cl maintains compatibility with msvc even in cases where it’s non standards compliant (eg 2 phase name lookup), but we try to keep these cases few and far between. To help me understand your case, do you mean you copy windows.h and modify it? How does this lead to the same struct being defined twice? If i were to write this: struct Foo {}; struct Foo {}; Is this a small repro of the issue

Thanks for the tips, I now have something that reads the obj file, finds .debug$T sections and global hashes it (proof of concept kind of code). What I can't find is: how does clang itself writes the coff files with global hashes, as that might help me understand how to create the .debug$H section, how to update the file section count and how to properly write this back. The code on yaml2coff

This is pretty gross, honestly :) Can't you just use using declarations? namespace Win32 { extern "C" { using ::BOOL; using ::LONG; using ::POINT; using ::LPPOINT; using ::GetCursorPos; } } This works with clang-cl. On Mon, Jan 22, 2018 at 5:39 AM Leonardo Santagada <santagada at gmail.com> wrote: > Here it is a minimal example, we do this so we don't have to

It is super gross, but we copy parts of windows.h because having all of it if both gigantic and very very messy. So our win32.h has a couple thousands of lines and not 30k+ for windows.h and we try to have zero macros. Win32.h doesn't include windows.h so using ::BOOL wouldn't work. We don't want to create a namespace, we just want a cleaner interface to windows api. The namespace with

Ok some information was lost on getting this example to you, I'm sorry for not being clear. We have a huge code base, let's say 90% of it doesn't include either header, 9% include win32.h and 1% includes both, I will try to discover why, but my guess is they include both a third party that includes windows.h and some of our libs that use win32.h. I will try to fully understand this

Hi, Is anyone working on making the PDB generation on LLD faster? Looking of a trace for linking one of our binaries (it takes 1min6s-1min20s) I see two things: 1) LookupBucketFor(Val, ConstFoundBucket); takes 35s so almost half of the time of linking, mostly finding duplicates 2) There is no parallelization inside of addObjectsToPDB Is anyone working on those? Also has anyone thought about

Hi, I finally got my first .obj file patched with .debug$H to look somewhat right. I added the new section at the end of the file so I don't have to recalculate all sections (although now I probably could position it in the middle, knowing that each section is: SizeOfRawData + (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right after $T in the file). That although

You said win32.h doesn't include windows.h, but main.cpp does. So what's the disadvantage of just including it in win32.h anyway, since it's already going to be in every translation unit? (Unless you didn't mean to #include it in main.cpp) I guess all I can do is warn you how bad of an idea this is. For starters, I already found a bug in your code ;-) // stdint.h typedef int