similar to: yaml2obj support for COFF debug directories

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

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

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

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

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

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

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

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

Any idea on how to create this new symbol there? I saw that there is a symbol pointing to each section, but didn't understand the format, and yaml2obj doesn't check it or do anything with the list. On Thu, Jan 25, 2018 at 6:56 PM, Leonardo Santagada <santagada at gmail.com> wrote: > YES, THANK YOU... I WAS THINKING THIS BUT COMPLETELY FORGOT. > > sorry for the caps... long

The debug information is actually still in a different format in the .bc file, it is LLVM metadata. I think the best reference for it is here: https://llvm.org/docs/SourceLevelDebugging.html#ccxx-frontend You can dump it just by disassembling the .bc file to textual IR using llvm-dis and examining the !DI* metadata nodes. You will have to run the file through llc to generate an object file to

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

Actually I already have a theory that even though you are adding the section to the section table, you might not be adding a *symbol* for the section to the symbol table. So the existing symbols (which reference sections by index) will all be wrong because you've inserted a new section. Still though, obj2yaml would expose that. On Thu, Jan 25, 2018 at 9:50 AM Zachary Turner <zturner at

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

Thank you for your reply. When I'm running "llvm-readobj" on an .obj file I get a result like shown in my attachment. This is very easy to read. I don't know if this is the codeview format. I would like to get this kind of debug information form a .bc file too, because I JIT them and wanted to try to build a debugger. With the file from "llvm-readobj" I see no

I see that there is an auxsymbol per section symbol, and also on the yaml representation there is a checksum, selection and unused all of them I have no idea how to fill in, also this aux symbol might have some important information for me to patch on the other symbols. Can you find the part in llvm that it writes those? because at least for auxsymbol the yaml part of the code threats as a binary

Hi, Thanks for your patch, Huang. It looks good to me. Just one comment: can you write a testcase, similar to the others used for linker script testing, with your example? Alternatively, you can modify lld/test/elf/linkerscript/sections-with-wildcards.test to test your case. This will make your patch complete and ready for commit, and will ensure we do not regress on this bug if this code is ever

I'm so close I can almost smell it :) I know how bad the code looks, I don't intend to submit this, but if you want to try it out its at: https://gist.github.com/santagada/544136b1ee143bf31653b1158ac6829e I'm seeing: lld-link.exe: error: duplicate symbol: "<redacted_unmangled>" (<redacted>) in <internal> and in <redacted_filename>.obj, looking at the