similar to: Extending llvm-objcopy to support COFF

Displaying 20 results from an estimated 9000 matches similar to: "Extending llvm-objcopy to support COFF"

2018 Mar 07
0
Extending llvm-objcopy to support COFF
Hi Zach! I've been thinking a bit about this for a while now and I'm still of two opinions: On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Currently llvm-objcopy only supports ELF files, and most of it's command > line flags are ELF / DWARF specific that don't make any sense on COFF > files. So a useful set of
2018 Mar 07
2
Extending llvm-objcopy to support COFF
On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Zach! > > I've been thinking a bit about this for a while now and I'm still of two > opinions: > > On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Currently llvm-objcopy only supports ELF
2018 Mar 08
0
Extending llvm-objcopy to support COFF
Hi, It's not clear to me what you mean by CLI "subcommands". Would you mind giving a brief example? Up to now, we've been trying to keep llvm-objcopy as close as possible to GNU objcopy, to make transitioning between them easier (I'm thinking in particular things like DWO generation). There are a small number of edge cases/unusual behaviours that we have chosen not to
2018 Mar 13
2
Extending llvm-objcopy to support COFF
Hey everyone, Sorry to jump in on this so late. My two cents is that it should remain GNU objoppy compatible most likely. It was always vaguely a desire to have command line compatibility but it has turned out over time that this is actually a crucial feature and should be one of the top priorities. You can't just go into a giant build system and swap out all the uses of GNU objcopy with
2018 Oct 01
5
Extending llvm-objcopy to support Mach-O
Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O
2018 Jan 19
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2017 Jun 02
8
llvm-objcopy proposal
LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build
2018 Jan 20
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 20
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 20
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 19
4
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 20
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 19
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
On Fri, Jan 19, 2018 at 12:44 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> 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,
2018 Jan 20
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 20
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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, >
2018 Jan 20
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 22
2
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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
2018 Jan 20
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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% >
2019 Jan 24
2
[cfe-dev] [8.0.0 Release] One week to the branch
On Thu, 24 Jan 2019, Hans Wennborg wrote: > On Thu, Jan 24, 2019 at 3:51 AM Martin Storsjö <martin at martin.st> wrote: >> >> FWIW, I've got the main COFF functionality that I had planned on doing >> committed in trunk by now. So at least for my own usecases, it's fully >> functional by now. (And for unsupported options, it clearly errors out.) >>
2018 Jan 21
0
[lldb-dev] Trying out lld to link windows binaries (using msvc as a compiler)
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