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

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

>
> 1 - Rip out the COFF support in the branch and let it error out as it did
> before.
>
> 2 - Add a custom patch for the branch, which makes the tool error out if
> an option that is known to be unimplemented/incomplete is specified,
> keeping the functionality that is known to be complete.
>
> 3 - Merge the llvm-objcopy/COFF patches to the release branch as things
> are completed in trunk during the rc phase, hopefully reaching a more
> complete state within that timeframe. As this is a new feature, it
> shouldn't have any stability impact on the rest (at least as long as we
> don't end up needing to patch other libraries in the process).
>
> What do you think?
>
> // Martin
>
> On Wed, 9 Jan 2019, Hans Wennborg via cfe-dev wrote:
>
> > Hello everyone,
> >
> > This is just a quick reminder that the upcoming release branch is
> > scheduled for creation one week from today, on Wednesday 16 January
> > 2019.
> >
> > The full schedule is available under "Upcoming Releases" in
the right
> > column at https://llvm.org.
> >
> > Please try to avoid committing disruptive changes just before or after
> > the branch.
> >
> > As the branch is created, the trunk version will become 9.0.0.
> >
> > Thanks,
> > Hans
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190111/16b70fac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190111/16b70fac/attachment.bin>

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.
>> 1 - Rip out the COFF support in the branch and let it error out as it
did
>> before.
>>
>> 2 - Add a custom patch for the branch, which makes the tool error out
if
>> an option that is known to be unimplemented/incomplete is specified,
>> keeping the functionality that is known to be complete.
>>
>> 3 - Merge the llvm-objcopy/COFF patches to the release branch as things
>> are completed in trunk during the rc phase, hopefully reaching a more
>> complete state within that timeframe. As this is a new feature, it
>> shouldn't have any stability impact on the rest (at least as long
as we
>> don't end up needing to patch other libraries in the process).
>>
>> What do you think?
>>
>> // Martin
>>
>> On Wed, 9 Jan 2019, Hans Wennborg via cfe-dev wrote:
>>
>> > Hello everyone,
>> >
>> > This is just a quick reminder that the upcoming release branch is
>> > scheduled for creation one week from today, on Wednesday 16
January
>> > 2019.
>> >
>> > The full schedule is available under "Upcoming Releases"
in the right
>> > column at https://llvm.org.
>> >
>> > Please try to avoid committing disruptive changes just before or
after
>> > the branch.
>> >
>> > As the branch is created, the trunk version will become 9.0.0.
>> >
>> > Thanks,
>> > Hans
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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