Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 1 Aug 2019 at 18:54, Enji Cooper wrote: > > Thought: could this be modified in an iterative manner, like “objdump” -> > “gobjdump” / “llvm-objdump” -> “objdump”, etc (assuming llvm and gnu objdump > are largely compatible)? It could, and we have done that sort of thing in the past. But here we should be retiring the old binutils tools well before 13.0 and I don't think it's worth the extra complexity. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
> On Jul 31, 2019, at 19:58, Ed Maste wrote: > >> On Thu, 1 Aug 2019 at 12:35, Ian Lepore wrote: >> >> Why would we provide no objdump? I use it quite frequently; it seems >> like an essential part of the toolchain to me. > > I don't want us to provide no objdump, but providing GNU objdump > 2.17.50 indefinitely is not a viable option; see PR 218387[1] for an > example of the kind of issue we have with providing obsolete software. > > We have a choice of: > 1. provide llvm-objdump, and no /usr/bin/objdump in the base system > 2. install llvm-objdump as /usr/bin/objdump > 3. require that users who want an objdump install the binutils port > > /usr/bin/objdump is not required by the base system build and not > required by most ports. exp-run details with no /usr/bin/objdump can > be found in PR 212319[2], and PR 229046[3] is a tracking PR for > removing dependencies on objdump. > > Option 1 (removing /usr/bin/objdump) is proposed in review D7338[4] > while option 2 is (installing llvm-objdump as objdump) is proposed in > review D18307. llvm-objdump is roughly compatible with GNU objdump > (command line and output format) but there are a large number of small > issues that will likely trip up scripted or automated objdump use. > (Scripts should probably just use readelf instead, though.) D18307 has > a list of LLVM bug reports for known issues in llvm-objdump. > > Note also that we currently provide only two or three obsolete > binutils, depending on the CPU architecture: > - as > - ld > - objdump > > [1] https://bugs.freebsd.org/218387 > [2] https://bugs.freebsd.org/212319 > [3] https://bugs.freebsd.org/229046 > [4] https://reviews.freebsd.org/D7338 > [5] https://reviews.freebsd.org/D18307 Thought: could this be modified in an iterative manner, like “objdump” -> “gobjdump” / “llvm-objdump” -> “objdump”, etc (assuming llvm and gnu objdump are largely compatible)? Thanks :)! -Enji ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
> On Thu, 2019-08-01 at 10:39 -0700, John Baldwin wrote: > > On 7/31/19 8:13 PM, Ed Maste wrote: > > > On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes < > > > free...@gndrsh.dnsmgr.net> wrote: > > > > > > > > That would be fine, the important thing is that the > > > > r350505 gets listed in the file, > > > > > > I don't see any reason that r350505 specifically should be in a > > > release note - this is a minor clarification of an existing > > > deprecation notice. It seems having an overall "deprecation > > > notices" > > > section in the release notes would make sense, but they should > > > really > > > persist from version to version. Should we add a top-level > > > DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with > > > some > > > sort of comment in the source so they can be found with a 'grep' > > > during release preparation? > > > > I think it would make sense to have "sections" in RELNOTES that mimic > > the sections we have in the existing release notes (e.g. kernel vs > > userland). That is effectively what GDB does with a top level NEWS > > file. This approach would hopefully make it easier to translate this > > file into the real release notes. It also means that a given "note" > > can evolve over time (e.g. it might start with "XYZ is deprecated" to > > "XYZ is removed" if a deprecation note is added and merged and later > > it > > is removed) rather than only having a running journal ala UPDATING. > > > > On the question of whether we want a dedicated section just for > > deprecation notices, I'm not sure. Probably we can just stick with > > the > > layout of our existing release notes? > > > > I wonder why it is that this relnotes file is some kind of major > attractor for complexity? > > As I understand it, the *entire* intent of this file was "if you forget > to add Relnotes: yes" to a commit, this gives you a way to flag the > commit after the fact, since commit messages are immutable. > > If people realize they forgot Relnotes: yes, and the remedy for that is > that they have to spelunk around in some complex formatted file to find > the "right section" (whatever that means)... well, I think in the real > world: they won't. That was my original intent when "I" first proposed this, imho that is as simple as it needs to be. Markj then later proposed this file here in a review, which I did give some feedback on, and here we are now, having discussion that probably would of better been had during a wider review process. Regards, Rod -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On 8/1/19 11:09 AM, Ian Lepore wrote: > On Thu, 2019-08-01 at 10:39 -0700, John Baldwin wrote: >> On 7/31/19 8:13 PM, Ed Maste wrote: >>> On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes < >>> free...@gndrsh.dnsmgr.net> wrote: That would be fine, the important thing is that the r350505 gets listed in the file, >>> >>> I don't see any reason that r350505 specifically should be in a >>> release note - this is a minor clarification of an existing >>> deprecation notice. It seems having an overall "deprecation >>> notices" >>> section in the release notes would make sense, but they should >>> really >>> persist from version to version. Should we add a top-level >>> DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with >>> some >>> sort of comment in the source so they can be found with a 'grep' >>> during release preparation? >> >> I think it would make sense to have "sections" in RELNOTES that mimic >> the sections we have in the existing release notes (e.g. kernel vs >> userland). That is effectively what GDB does with a top level NEWS >> file. This approach would hopefully make it easier to translate this >> file into the real release notes. It also means that a given "note" >> can evolve over time (e.g. it might start with "XYZ is deprecated" to >> "XYZ is removed" if a deprecation note is added and merged and later >> it >> is removed) rather than only having a running journal ala UPDATING. >> >> On the question of whether we want a dedicated section just for >> deprecation notices, I'm not sure. Probably we can just stick with >> the >> layout of our existing release notes? >> > > I wonder why it is that this relnotes file is some kind of major > attractor for complexity? > > As I understand it, the *entire* intent of this file was "if you forget > to add Relnotes: yes" to a commit, this gives you a way to flag the > commit after the fact, since commit messages are immutable. > > If people realize they forgot Relnotes: yes, and the remedy for that is > that they have to spelunk around in some complex formatted file to find > the "right section" (whatever that means)... well, I think in the real > world: they won't. My assumption was that relnotes would remain a simple text file. I think the win is that you aren't editing XML or SGML or the like, and that you can go back and edit existing entries if needed as well as document something when you missed relnotes: yes. The more work we put into having something closer to the finished product in this file, the less work re@ has to do to parse commit messages. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 2019-08-01 at 10:39 -0700, John Baldwin wrote: > On 7/31/19 8:13 PM, Ed Maste wrote: > > On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes < > > free...@gndrsh.dnsmgr.net> wrote: > > > > > > That would be fine, the important thing is that the > > > r350505 gets listed in the file, > > > > I don't see any reason that r350505 specifically should be in a > > release note - this is a minor clarification of an existing > > deprecation notice. It seems having an overall "deprecation > > notices" > > section in the release notes would make sense, but they should > > really > > persist from version to version. Should we add a top-level > > DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with > > some > > sort of comment in the source so they can be found with a 'grep' > > during release preparation? > > I think it would make sense to have "sections" in RELNOTES that mimic > the sections we have in the existing release notes (e.g. kernel vs > userland). That is effectively what GDB does with a top level NEWS > file. This approach would hopefully make it easier to translate this > file into the real release notes. It also means that a given "note" > can evolve over time (e.g. it might start with "XYZ is deprecated" to > "XYZ is removed" if a deprecation note is added and merged and later > it > is removed) rather than only having a running journal ala UPDATING. > > On the question of whether we want a dedicated section just for > deprecation notices, I'm not sure. Probably we can just stick with > the > layout of our existing release notes? > I wonder why it is that this relnotes file is some kind of major attractor for complexity? As I understand it, the *entire* intent of this file was "if you forget to add Relnotes: yes" to a commit, this gives you a way to flag the commit after the fact, since commit messages are immutable. If people realize they forgot Relnotes: yes, and the remedy for that is that they have to spelunk around in some complex formatted file to find the "right section" (whatever that means)... well, I think in the real world: they won't. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On 7/31/19 8:13 PM, Ed Maste wrote: > On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes > wrote: >> >> That would be fine, the important thing is that the >> r350505 gets listed in the file, > > I don't see any reason that r350505 specifically should be in a > release note - this is a minor clarification of an existing > deprecation notice. It seems having an overall "deprecation notices" > section in the release notes would make sense, but they should really > persist from version to version. Should we add a top-level > DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with some > sort of comment in the source so they can be found with a 'grep' > during release preparation? I think it would make sense to have "sections" in RELNOTES that mimic the sections we have in the existing release notes (e.g. kernel vs userland). That is effectively what GDB does with a top level NEWS file. This approach would hopefully make it easier to translate this file into the real release notes. It also means that a given "note" can evolve over time (e.g. it might start with "XYZ is deprecated" to "XYZ is removed" if a deprecation note is added and merged and later it is removed) rather than only having a running journal ala UPDATING. On the question of whether we want a dedicated section just for deprecation notices, I'm not sure. Probably we can just stick with the layout of our existing release notes? -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, Aug 01, 2019 at 11:22:46AM -0500, Warner Losh wrote: > On Thu, Aug 1, 2019, 11:00 AM Rodney W. Grimes > wrote: > > > > Author: emaste > > > Date: Thu Aug 1 14:42:41 2019 > > > New Revision: 350505 > > > URL: https://svnweb.freebsd.org/changeset/base/350505 > > > > > > Log: > > > objdump: be explicit that GNU objdump that will be removed > > > > > > We may install llvm-objdump as objdump (see review D18307) or just > > > provide no /usr/bin/objdump, but either way GNU objdump won't be > > > installed in the future. > > > > > > MFC after: 3 days > > > > Can we get a RELNOTES entry for this please? > > > > Great idea. What's the protocol the project wants here? It seems to me that > we'd want a world where either the original committer or folks shepherding > the release notes out the door when the time comes could commit entries to > the file. We should encourage the OC to do it, but have the culture that we > can be relaxed about others doing it too so we have low friction around > this file. This is basically how UPDATING works. It's reasonable to reply to a commit mail and ask the committer to consider adding a RELNOTES entry, perhaps proposing some text. And if the committer doesn't follow up, there's no problem with just going ahead and committing the new entry. That said, I would think that an actual removal of GNU objdump would be the commit that deserves a RELNOTES entry, not this one. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 1 Aug 2019 at 12:51, Rodney W. Grimes wrote: > > That would be fine, the important thing is that the > r350505 gets listed in the file, I don't see any reason that r350505 specifically should be in a release note - this is a minor clarification of an existing deprecation notice. It seems having an overall "deprecation notices" section in the release notes would make sense, but they should really persist from version to version. Should we add a top-level DEPRECATION_NOTICES file perhaps? Or tag deprecation notices with some sort of comment in the source so they can be found with a 'grep' during release preparation? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 1 Aug 2019 at 12:35, Ian Lepore wrote: > > Why would we provide no objdump? I use it quite frequently; it seems > like an essential part of the toolchain to me. I don't want us to provide no objdump, but providing GNU objdump 2.17.50 indefinitely is not a viable option; see PR 218387[1] for an example of the kind of issue we have with providing obsolete software. We have a choice of: 1. provide llvm-objdump, and no /usr/bin/objdump in the base system 2. install llvm-objdump as /usr/bin/objdump 3. require that users who want an objdump install the binutils port /usr/bin/objdump is not required by the base system build and not required by most ports. exp-run details with no /usr/bin/objdump can be found in PR 212319[2], and PR 229046[3] is a tracking PR for removing dependencies on objdump. Option 1 (removing /usr/bin/objdump) is proposed in review D7338[4] while option 2 is (installing llvm-objdump as objdump) is proposed in review D18307. llvm-objdump is roughly compatible with GNU objdump (command line and output format) but there are a large number of small issues that will likely trip up scripted or automated objdump use. (Scripts should probably just use readelf instead, though.) D18307 has a list of LLVM bug reports for known issues in llvm-objdump. Note also that we currently provide only two or three obsolete binutils, depending on the CPU architecture: - as - ld - objdump [1] https://bugs.freebsd.org/218387 [2] https://bugs.freebsd.org/212319 [3] https://bugs.freebsd.org/229046 [4] https://reviews.freebsd.org/D7338 [5] https://reviews.freebsd.org/D18307 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
> On Thu, 1 Aug 2019 at 12:00, Rodney W. Grimes > wrote: > > > > > Author: emaste > > > Date: Thu Aug 1 14:42:41 2019 > > > New Revision: 350505 > > > URL: https://svnweb.freebsd.org/changeset/base/350505 > > > > > > Log: > > > objdump: be explicit that GNU objdump that will be removed > > > > > > We may install llvm-objdump as objdump (see review D18307) or just > > > provide no /usr/bin/objdump, but either way GNU objdump won't be > > > installed in the future. > > > > > > MFC after: 3 days > > > > Can we get a RELNOTES entry for this please? > > Can you suggest wording for such a note? Something like: > > The deprecation notice in the GNU objdump man page was clarified to > indicate that it is GNU objdump which will be removed; an objdump from > the LLVM project may be provided in its place. That would be fine, the important thing is that the r350505 gets listed in the file, the people who shall actually have to write the release notes simply need a key to let them know they should look at this commit and create a proper entry. I did not set the policy or write the current RELNOTES file, so markj and gjb have far more to say here than anything I do. Regards, -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 1 Aug 2019 at 12:00, Rodney W. Grimes wrote: > > > Author: emaste > > Date: Thu Aug 1 14:42:41 2019 > > New Revision: 350505 > > URL: https://svnweb.freebsd.org/changeset/base/350505 > > > > Log: > > objdump: be explicit that GNU objdump that will be removed > > > > We may install llvm-objdump as objdump (see review D18307) or just > > provide no /usr/bin/objdump, but either way GNU objdump won't be > > installed in the future. > > > > MFC after: 3 days > > Can we get a RELNOTES entry for this please? Can you suggest wording for such a note? Something like: The deprecation notice in the GNU objdump man page was clarified to indicate that it is GNU objdump which will be removed; an objdump from the LLVM project may be provided in its place. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, 2019-08-01 at 14:42 +, Ed Maste wrote: > Author: emaste > Date: Thu Aug 1 14:42:41 2019 > New Revision: 350505 > URL: https://svnweb.freebsd.org/changeset/base/350505 > > Log: > objdump: be explicit that GNU objdump that will be removed > > We may install llvm-objdump as objdump (see review D18307) or just > provide no /usr/bin/objdump, but either way GNU objdump won't be > installed in the future. > Why would we provide no objdump? I use it quite frequently; it seems like an essential part of the toolchain to me. -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
On Thu, Aug 1, 2019, 11:00 AM Rodney W. Grimes
wrote:
> > Author: emaste
> > Date: Thu Aug 1 14:42:41 2019
> > New Revision: 350505
> > URL: https://svnweb.freebsd.org/changeset/base/350505
> >
> > Log:
> > objdump: be explicit that GNU objdump that will be removed
> >
> > We may install llvm-objdump as objdump (see review D18307) or just
> > provide no /usr/bin/objdump, but either way GNU objdump won't be
> > installed in the future.
> >
> > MFC after: 3 days
>
> Can we get a RELNOTES entry for this please?
>
Great idea. What's the protocol the project wants here? It seems to me that
we'd want a world where either the original committer or folks shepherding
the release notes out the door when the time comes could commit entries to
the file. We should encourage the OC to do it, but have the culture that we
can be relaxed about others doing it too so we have low friction around
this file.
Warner
> Modified:
> > head/contrib/binutils/binutils/doc/binutils.texi
> > head/gnu/usr.bin/binutils/objdump/objdump.1
> >
> > Modified: head/contrib/binutils/binutils/doc/binutils.texi
> >
> ==
> > --- head/contrib/binutils/binutils/doc/binutils.texi Thu Aug 1
> 14:40:37 2019(r350504)
> > +++ head/contrib/binutils/binutils/doc/binutils.texi Thu Aug 1
> 14:42:41 2019(r350505)
> > @@ -1624,8 +1624,8 @@ program to compile and work.
> > specify archives, @command{objdump} shows information on each of the
> member
> > object files.
> >
> > -@command{objdump} will be removed from a future version of the
> > -FreeBSD base system. Users who require @command{objdump} are advised
> > +GNU @command{objdump} will be removed from a future version of the
> > +FreeBSD base system. Users who require GNU @command{objdump} are
> advised
> > to install the binutils port or package.
> >
> > @c man end
> >
> > Modified: head/gnu/usr.bin/binutils/objdump/objdump.1
> >
> ==
> > --- head/gnu/usr.bin/binutils/objdump/objdump.1 Thu Aug 1
> 14:40:37 2019(r350504)
> > +++ head/gnu/usr.bin/binutils/objdump/objdump.1 Thu Aug 1
> 14:42:41 2019(r350505)
> > @@ -183,8 +183,8 @@ program to compile and work.
> > specify archives, \fBobjdump\fR shows information on each of the member
> > object files.
> > .PP
> > -\&\fBobjdump\fR will be removed from a future version of the
> > -FreeBSD base system. Users who require \&\fBobjdump\fR are advised
> > +GNU \&\fBobjdump\fR will be removed from a future version of the
> > +FreeBSD base system. Users who require GNU \&\fBobjdump\fR are advised
> > to install the binutils port or package.
> > .SH "OPTIONS"
> > .IX Header "OPTIONS"
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350505 - in head: contrib/binutils/binutils/doc gnu/usr.bin/binutils/objdump
> Author: emaste
> Date: Thu Aug 1 14:42:41 2019
> New Revision: 350505
> URL: https://svnweb.freebsd.org/changeset/base/350505
>
> Log:
> objdump: be explicit that GNU objdump that will be removed
>
> We may install llvm-objdump as objdump (see review D18307) or just
> provide no /usr/bin/objdump, but either way GNU objdump won't be
> installed in the future.
>
> MFC after: 3 days
Can we get a RELNOTES entry for this please?
> Modified:
> head/contrib/binutils/binutils/doc/binutils.texi
> head/gnu/usr.bin/binutils/objdump/objdump.1
>
> Modified: head/contrib/binutils/binutils/doc/binutils.texi
> ==
> --- head/contrib/binutils/binutils/doc/binutils.texi Thu Aug 1 14:40:37
> 2019(r350504)
> +++ head/contrib/binutils/binutils/doc/binutils.texi Thu Aug 1 14:42:41
> 2019(r350505)
> @@ -1624,8 +1624,8 @@ program to compile and work.
> specify archives, @command{objdump} shows information on each of the member
> object files.
>
> -@command{objdump} will be removed from a future version of the
> -FreeBSD base system. Users who require @command{objdump} are advised
> +GNU @command{objdump} will be removed from a future version of the
> +FreeBSD base system. Users who require GNU @command{objdump} are advised
> to install the binutils port or package.
>
> @c man end
>
> Modified: head/gnu/usr.bin/binutils/objdump/objdump.1
> ==
> --- head/gnu/usr.bin/binutils/objdump/objdump.1 Thu Aug 1 14:40:37
> 2019(r350504)
> +++ head/gnu/usr.bin/binutils/objdump/objdump.1 Thu Aug 1 14:42:41
> 2019(r350505)
> @@ -183,8 +183,8 @@ program to compile and work.
> specify archives, \fBobjdump\fR shows information on each of the member
> object files.
> .PP
> -\&\fBobjdump\fR will be removed from a future version of the
> -FreeBSD base system. Users who require \&\fBobjdump\fR are advised
> +GNU \&\fBobjdump\fR will be removed from a future version of the
> +FreeBSD base system. Users who require GNU \&\fBobjdump\fR are advised
> to install the binutils port or package.
> .SH "OPTIONS"
> .IX Header "OPTIONS"
>
>
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
