similar to: [lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)

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 lot of other .cpp's in them aka munch files) but still have a lot of single .cpp's as well (in total something like 3.4k

Zachary, Do you generally recommend using -mllvm -emit-codeview-ghash-section and /DEBUG:GHASH when linking for Windows? On Fri, Jan 19, 2018 at 3:17 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > -lldb-dev, +llvm-dev > > lldb-dev is specifically for the llvm debugger, and llvm-dev is for > everything else (including lld) > > Did you compile 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

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 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

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

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

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

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% >

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, >

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

Hmm, ok. In that case let me try again without my local changes. Maybe they are getting in the way :-/ On Fri, Jan 26, 2018 at 9:51 AM Leonardo Santagada <santagada at gmail.com> wrote: > it is identical to me... wierd. > > On Fri, Jan 26, 2018 at 6:49 PM, Zachary Turner <zturner at google.com> > wrote: > >> (Ignore the fact that my hashes are 8 byte in the

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

I'm pretty confident that cl is not putting anything strange in the .debug$T sections. We've done a lot of testing and never seen anything except CodeView type records in a .debug$T. My hunch is that your objcopy patch is probably not doing the right thing in one or more of the section headers, and this is confusing the linker. One idea might be to build a simple object file with

I'm now thinking that there's a bug in either obj2yaml or yaml2obj, because if I run just those two tools on my codebase it generates yaml files that can't be decoded, will try now to not add any section to the obj file in llvm-objcopy to see if I can link with obj files that I rewrite (but without adding symbols or sections). One of the bugs that do annoy me is that the timedatestamp

Yea as long as you compare clang-cl object file with automatically generated .debug$H section against clang-cl object file without .debug$H but added after the fact with llvm-objcopy, that should expose the problem I think when you run obj2yaml on them. On Thu, Jan 25, 2018 at 9:49 AM Leonardo Santagada <santagada at gmail.com> wrote: > I did reorder my sections, so that .debug$H is in

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

(Ignore the fact that my hashes are 8 byte in the "good" file, this is due to some local changes I've been experimenting with) On Fri, Jan 26, 2018 at 9:48 AM Zachary Turner <zturner at google.com> wrote: > I did this: > > // a.cpp > static int x = 0; > void b(int); > void a(int) { > if (x) > b(x); > } > int main(int argc, char **argv) {

I did reorder my sections, so that .debug$H is in the correct place, but now I get some errors on dubplicate symbols, I created a folder with examples: https://www.dropbox.com/sh/nmvzi44pi0boe76/AAA0f47O5PCJ9JiUc6wVuwBra?dl=0 t.obj is generated by vs 2015 and it links fine with lld-link.exe, but tout.obj gives this errors: lld-link.exe /DEBUG:GHASH tout.obj LLD-LINK.EXE: error: duplicate

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