[llvm-dev] [cfe-dev] [8.0.0 Release] One week to the branch

Martin Storsjö via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 24 03:51:29 PST 2019


On Tue, 15 Jan 2019, Hans Wennborg wrote:

> On Sat, Jan 12, 2019 at 12:49 AM Jordan Rupprecht <rupprecht at google.com> wrote:
>>
>>
>>
>> On Fri, Jan 11, 2019 at 6:26 AM Martin Storsjö <martin at martin.st> wrote:
>>>
>>> Hi,
>>>
>>> The COFF support in llvm-objcopy is in a pretty half-finished state at the
>>> moment. I had hoped to have it mostly usable for the common scenarios by
>>> the time of the branch (the initial patch was sent at the end of
>>> November), but it's still lacking stripping of sections (while stripping
>>> of symbols is pretty much done) and a few other minor features I have
>>> waiting to be polished up according to review comments.
>>>
>>> When used right now, it won't error out or warn about not doing what
>>> actually was requested, but just copy the object/executable and do some
>>> symbol removals if requested.
>>>
>>> With the branch coming real soon, what's the preferred course of action?
>>>
>>> 0 - Do nothing, release this as is. As llvm-objcopy hasn't supported COFF
>>> before, nobody will try it and run into the issue.
>>
>> Option 0 seems fine to me
>
> I think this is fine too. If you want you could add a note somewhere
> that the COFF support is experimental and incomplete.

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

If there's an interest in this, it should be easy to backport to the 
release branch (with no regression risk, as I believe none of the patches 
since the branch touch anything outside of the COFF directory), but I 
don't have a direct need myself to have it in the release.

// Martin


More information about the llvm-dev mailing list