Auto generate ChangeLog for binutils commits?

Auto generate ChangeLog for binutils commits?

[H.J. Lu]

Hi,

I had an impression that ChangeLog was auto generated for GDB commits.
If it is true, should we do the same for binutils commits?

-- 
H.J.

Re: Auto generate ChangeLog for binutils commits?

[Simon Marchi]

On 2020-05-26 1:07 p.m., H.J. Lu via Gdb wrote:
> Hi,
> 
> I had an impression that ChangeLog was auto generated for GDB commits.
> If it is true, should we do the same for binutils commits?
> 
> -- 
> H.J.
> 

No we (GDB) don't do that.  There was a discussion here

  https://sourceware.org/pipermail/gdb-patches/2020-February/165728.html

But it didn't go anywhere.  Note that when I actually tried the script, it
didn't produce good results (perhaps because it wasn't designed with C++
in mind).

Simon

Re: Auto generate ChangeLog for binutils commits?

[H.J. Lu]

On Wed, May 27, 2020 at 7:10 AM Simon Marchi <simark@simark.ca> wrote:
>
> On 2020-05-26 1:07 p.m., H.J. Lu via Gdb wrote:
> > Hi,
> >
> > I had an impression that ChangeLog was auto generated for GDB commits.
> > If it is true, should we do the same for binutils commits?
> >
> > --
> > H.J.
> >
>
> No we (GDB) don't do that.  There was a discussion here
>
>   https://sourceware.org/pipermail/gdb-patches/2020-February/165728.html
>
> But it didn't go anywhere.  Note that when I actually tried the script, it
> didn't produce good results (perhaps because it wasn't designed with C++
> in mind).

GCC will auto generate ChangeLog entry from git commit message.  Can
binutils+gdb do the same?


-- 
H.J.

Re: Auto generate ChangeLog for binutils commits?

[Simon Marchi]

On 2020-05-27 10:20 a.m., H.J. Lu wrote:
> On Wed, May 27, 2020 at 7:10 AM Simon Marchi <simark@simark.ca> wrote:
>>
>> On 2020-05-26 1:07 p.m., H.J. Lu via Gdb wrote:
>>> Hi,
>>>
>>> I had an impression that ChangeLog was auto generated for GDB commits.
>>> If it is true, should we do the same for binutils commits?
>>>
>>> --
>>> H.J.
>>>
>>
>> No we (GDB) don't do that.  There was a discussion here
>>
>>   https://sourceware.org/pipermail/gdb-patches/2020-February/165728.html
>>
>> But it didn't go anywhere.  Note that when I actually tried the script, it
>> didn't produce good results (perhaps because it wasn't designed with C++
>> in mind).
> 
> GCC will auto generate ChangeLog entry from git commit message.  Can
> binutils+gdb do the same?

Can you please explain what this means?  I suspect that we are not talking about
the same thing.  You mean, still write the ChangeLog entry by hand, but only put
it in the git commit.  And then a script scrapes all the commit messages in order
to produce a ChangeLog file?

Simon

Auto update ChangeLog for binutils+gdb commits?

[H.J. Lu]

On Wed, May 27, 2020 at 7:29 AM Simon Marchi <simark@simark.ca> wrote:
>
> On 2020-05-27 10:20 a.m., H.J. Lu wrote:
> > On Wed, May 27, 2020 at 7:10 AM Simon Marchi <simark@simark.ca> wrote:
> >>
> >> On 2020-05-26 1:07 p.m., H.J. Lu via Gdb wrote:
> >>> Hi,
> >>>
> >>> I had an impression that ChangeLog was auto generated for GDB commits.
> >>> If it is true, should we do the same for binutils commits?
> >>>
> >>> --
> >>> H.J.
> >>>
> >>
> >> No we (GDB) don't do that.  There was a discussion here
> >>
> >>   https://sourceware.org/pipermail/gdb-patches/2020-February/165728.html
> >>
> >> But it didn't go anywhere.  Note that when I actually tried the script, it
> >> didn't produce good results (perhaps because it wasn't designed with C++
> >> in mind).
> >
> > GCC will auto generate ChangeLog entry from git commit message.  Can
> > binutils+gdb do the same?
>
> Can you please explain what this means?  I suspect that we are not talking about
> the same thing.  You mean, still write the ChangeLog entry by hand, but only put
> it in the git commit.  And then a script scrapes all the commit messages in order
> to produce a ChangeLog file?
>

Yes.  I updated the email subject.  Personally, I think it is a good
exercise to document
what changes are in ChangeLog format in commit message.  But adding them to
ChangeLog files is a problem.   If git commit hooks can do it
automatically, it will
be very nice.  GCC will do it now.  Can we do the same?

-- 
H.J.

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/27/20 5:10 PM, H.J. Lu via Binutils wrote:
> be very nice.  GCC will do it now.  Can we do the same?

Hello.

I'm the author of the scripts that are currently used in the GCC.
As mentioned, we update ChangeLog files by a script that takes all
the ChangeLog entries from git commit message. The supported ChangeLog
format is documented here:

https://gcc.gnu.org/codingconventions.html#ChangeLogs

and the corresponding script can be seen here:
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=contrib/gcc-changelog;h=2900264795a520b5fdf7ccd54f7a08a84dcc35f2;hb=HEAD

I briefly looked at binutils commits and I believe the scripts can
be directly adopted.

Martin

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On 5/29/20 9:45 AM, Martin Liška wrote:
> I briefly looked at binutils commits and I believe the scripts can
> be directly adopted.

Ok, one would need to adjust list of ChangeLog files and bugzilla components. I've changed
that in the attached patch.

With that one can test it:

$ ./contrib/gcc-changelog/git_check_commit.py -g ~/Programming/binutils -n HEAD~300..HEAD

(see the attached output)
So ~250/300 commit messages can be parsed.

And the generated ChangeLog can be seen with:

./contrib/gcc-changelog/git_check_commit.py -g ~/Programming/binutils -n HEAD~300..HEAD -p
(see the attached output)

Would you be interested in adoption of the script?
Martin

[-- Attachment #2: result.txt.bz2 --]
[-- Type: application/x-bzip, Size: 8942 bytes --]

[-- Attachment #3: result-changelog.txt.bz2 --]
[-- Type: application/x-bzip, Size: 24666 bytes --]

[-- Attachment #4: 0001-gcc-changelog-for-binutils.patch --]
[-- Type: text/x-patch, Size: 4643 bytes --]

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 084e83c18cc..e2be3843c83 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -20,110 +20,149 @@ import os
 import re
 
 changelog_locations = set([
+    'bfd',
+    'binutils',
     'config',
     'contrib',
-    'contrib/header-tools',
-    'contrib/reghunt',
-    'contrib/regression',
-    'fixincludes',
-    'gcc/ada',
-    'gcc/analyzer',
-    'gcc/brig',
-    'gcc/c',
-    'gcc/c-family',
-    'gcc',
-    'gcc/cp',
-    'gcc/d',
-    'gcc/fortran',
-    'gcc/go',
-    'gcc/jit',
-    'gcc/lto',
-    'gcc/objc',
-    'gcc/objcp',
-    'gcc/po',
-    'gcc/testsuite',
-    'gnattools',
-    'gotools',
+    'cpu',
+    'elfcpp',
+    'etc',
+    'gas',
+    'gdb',
+    'gdb/doc',
+    'gdbserver',
+    'gdb/stubs',
+    'gdbsupport',
+    'gdb/testsuite',
+    'gnulib',
+    'gold',
+    'gprof',
     'include',
+    'include/gdb',
     'intl',
-    'libada',
-    'libatomic',
-    'libbacktrace',
-    'libcc1',
-    'libcpp',
-    'libcpp/po',
+    'ld',
+    'libctf',
     'libdecnumber',
-    'libffi',
-    'libgcc',
-    'libgcc/config/avr/libf7',
-    'libgcc/config/libbid',
-    'libgfortran',
-    'libgomp',
-    'libhsail-rt',
     'libiberty',
-    'libitm',
-    'libobjc',
-    'liboffloadmic',
-    'libphobos',
-    'libquadmath',
-    'libsanitizer',
-    'libssp',
-    'libstdc++-v3',
-    'libvtv',
-    'lto-plugin',
-    'maintainer-scripts',
-    'zlib'])
+    'opcodes',
+    'readline',
+    'readline/readline/examples/rlfe',
+    'sim/aarch64',
+    'sim/arm',
+    'sim/avr',
+    'sim/bfin',
+    'sim',
+    'sim/common',
+    'sim/cr16',
+    'sim/cris',
+    'sim/d10v',
+    'sim/erc32',
+    'sim/frv',
+    'sim/ft32',
+    'sim/h8300',
+    'sim/igen',
+    'sim/iq2000',
+    'sim/lm32',
+    'sim/m32c',
+    'sim/m32r',
+    'sim/m68hc11',
+    'sim/mcore',
+    'sim/microblaze',
+    'sim/mips',
+    'sim/mn10300',
+    'sim/moxie',
+    'sim/msp430',
+    'sim/ppc',
+    'sim/pru',
+    'sim/rl78',
+    'sim/rx',
+    'sim/sh64',
+    'sim/sh',
+    'sim/testsuite',
+    'sim/testsuite/d10v-elf',
+    'sim/testsuite/frv-elf',
+    'sim/testsuite/m32r-elf',
+    'sim/testsuite/mips64el-elf',
+    'sim/testsuite/sim/aarch64',
+    'sim/testsuite/sim/arm',
+    'sim/testsuite/sim/avr',
+    'sim/testsuite/sim/bfin',
+    'sim/testsuite/sim/cr16',
+    'sim/testsuite/sim/cris',
+    'sim/testsuite/sim/fr30',
+    'sim/testsuite/sim/frv',
+    'sim/testsuite/sim/ft32',
+    'sim/testsuite/sim/h8300',
+    'sim/testsuite/sim/iq2000',
+    'sim/testsuite/sim/lm32',
+    'sim/testsuite/sim/m32c',
+    'sim/testsuite/sim/m32r',
+    'sim/testsuite/sim/m68hc11',
+    'sim/testsuite/sim/mcore',
+    'sim/testsuite/sim/microblaze',
+    'sim/testsuite/sim/mips',
+    'sim/testsuite/sim/mn10300',
+    'sim/testsuite/sim/moxie',
+    'sim/testsuite/sim/msp430',
+    'sim/testsuite/sim/or1k',
+    'sim/testsuite/sim/pru',
+    'sim/testsuite/sim/sh64',
+    'sim/testsuite/sim/sh64/compact',
+    'sim/testsuite/sim/sh64/media',
+    'sim/testsuite/sim/sh',
+    'sim/testsuite/sim/v850',
+    'sim/v850',
+    'zlib'
+])
 
 bug_components = set([
+    # GDB components
     'ada',
-    'analyzer',
-    'boehm-gc',
-    'bootstrap',
-    'c',
+    'backtrace',
+    'breakpoints',
+    'build',
     'c++',
+    'cli',
+    'compile',
+    'corefiles',
     'd',
-    'debug',
-    'demangler',
-    'driver',
-    'fastjar',
+    'exp',
+    'external',
     'fortran',
-    'gcov-profile',
+    'gdb',
     'go',
-    'hsa',
-    'inline-asm',
-    'ipa',
+    'guile',
+    'i18n',
     'java',
-    'jit',
-    'libbacktrace',
-    'libf2c',
-    'libffi',
-    'libfortran',
-    'libgcc',
-    'libgcj',
-    'libgomp',
-    'libitm',
-    'libobjc',
-    'libquadmath',
-    'libstdc++',
-    'lto',
-    'middle-end',
-    'modula2',
+    'm2',
+    'm3',
+    'macros',
+    'mi',
     'objc',
-    'objc++',
-    'other',
-    'pch',
-    'pending',
-    'plugins',
-    'preprocessor',
-    'regression',
-    'rtl-optimization',
-    'sanitizer',
-    'spam',
-    'target',
+    'pascal',
+    'python',
+    'record',
+    'remote',
+    'rust',
+    'server',
+    'shlibs',
+    'sim',
+    'symtab',
+    'tdep',
     'testsuite',
-    'translation',
-    'tree-optimization',
-    'web'])
+    'threads',
+    'tui',
+    'varobj',
+    'web',
+    'win32',
+    # Binutils components
+    'admin',
+    'binutils',
+    'gas',
+    'gold',
+    'gprof',
+    'ld',
+    'libctf'])
 
 ignored_prefixes = [
     'gcc/d/dmd/',

Re: Auto update ChangeLog for binutils+gdb commits?

[Tom Tromey]

Martin> I'm the author of the scripts that are currently used in the GCC.
Martin> As mentioned, we update ChangeLog files by a script that takes all
Martin> the ChangeLog entries from git commit message. The supported ChangeLog
Martin> format is documented here:

Martin> https://gcc.gnu.org/codingconventions.html#ChangeLogs

IIUC, we still have to write the ChangeLog entries by hand, just in the
commit message, and using a much stricter format.  Is that accurate?

If so, then this seems less convenient than the status quo.  At least
for me, editing the files is simpler -- I use scripts to handle the
merges, rebases, and date-updating; and Emacs provides direct support
for writing the entries in the correct files and it usually gets the
function name correct as well.

It's the convenience of the last part that I'm most concerned about
losing.  If there's a script that does as good a job, then maybe; but
otherwise it is a -1 from me.  My reasoning here is that editing a
ChangeLog entry is labor-intensive, and anything increasing the labor is
a negative.  It's already a reasonably significant drag on submitting
patches.

I'd be receptive to removing ChangeLog entirely.  I don't believe they
provide much value.  However, I know others disagree on this point, so I
don't plan to press it.

I'd also be open to changing the format to something requiring zero
manual intervention.  For example, if we could have a commit script that
simply listed the files and didn't require editing in the names of the
functions.

thanks,
Tom

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/29/20 2:15 PM, Tom Tromey wrote:
> Martin> I'm the author of the scripts that are currently used in the GCC.
> Martin> As mentioned, we update ChangeLog files by a script that takes all
> Martin> the ChangeLog entries from git commit message. The supported ChangeLog
> Martin> format is documented here:
> 
> Martin> https://gcc.gnu.org/codingconventions.html#ChangeLogs
> 
> IIUC, we still have to write the ChangeLog entries by hand, just in the
> commit message, and using a much stricter format.  Is that accurate?

Yes, the entries should be places to git message.

> 
> If so, then this seems less convenient than the status quo.  At least
> for me, editing the files is simpler -- I use scripts to handle the
> merges, rebases, and date-updating; and Emacs provides direct support
> for writing the entries in the correct files and it usually gets the
> function name correct as well.

For generation of ChangeLog template, you can use:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/mklog.py;h=243edbb15c522169709902b27a8558c6e0755107;hb=HEAD

It takes a diff a generates a template. Note that PR entries are auto-filled,
new and removed files are automatically added.

About the merges: it's a pain to make a backport (a.k.a) as you're very likely
conflict in ChangeLog entries. Having the ChangeLog entries in message one
can do simple git cherry-pick and it's done.

Note that quite all developers have self made scripts for these situations
and it seems to me an extra work everybody has to do.

> 
> It's the convenience of the last part that I'm most concerned about
> losing.  If there's a script that does as good a job, then maybe; but
> otherwise it is a -1 from me.  My reasoning here is that editing a
> ChangeLog entry is labor-intensive, and anything increasing the labor is
> a negative.  It's already a reasonably significant drag on submitting
> patches.
> 
> I'd be receptive to removing ChangeLog entirely.  I don't believe they
> provide much value.  However, I know others disagree on this point, so I
> don't plan to press it.
> 
> I'd also be open to changing the format to something requiring zero
> manual intervention.  For example, if we could have a commit script that
> simply listed the files and didn't require editing in the names of the
> functions.

Yes, mklog.py does that.

> 
> thanks,
> Tom
> 

Re: Auto update ChangeLog for binutils+gdb commits?

[Tom Tromey]

Martin> For generation of ChangeLog template, you can use:
Martin> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/mklog.py;h=243edbb15c522169709902b27a8558c6e0755107;hb=HEAD

Can it be used without manual intervention?
Or do I still have to edit in all the function names?
Could you run it on some recent gdb commits and show the output?

Martin> About the merges: it's a pain to make a backport (a.k.a) as you're very likely
Martin> conflict in ChangeLog entries. Having the ChangeLog entries in message one
Martin> can do simple git cherry-pick and it's done.

This is emphatically not the case for me.

Martin> About the date-updating: it's also pain to always update a timestamp before
Martin> a patch is installed.

What I'm saying is that it isn't a pain.  It's a single command before
pushing.  I can't remember the last time the scripts failed but it's
surely been more than 5 years.

I write a lot of patches in gdb and I have already filed off as many
annoying parts as I could -- which is why my default stance is not to
want to change.  Changing implies that maybe I'd have to redo this work.

Tom

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/29/20 2:44 PM, Tom Tromey wrote:
> Martin> For generation of ChangeLog template, you can use:
> Martin> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/mklog.py;h=243edbb15c522169709902b27a8558c6e0755107;hb=HEAD
> 
> Can it be used without manual intervention?
> Or do I still have to edit in all the function names?

One only needs to describe what's purpose of a change.

> Could you run it on some recent gdb commits and show the output?

Sure:

$ git format-patch -1 2b2558bfacba3813863da6728c021eb89fa34677 && ~/Programming/gcc/contrib/mklog.py 00*
0001-Move-DWARF-constant-stringifying-code-to-new-file.patch

ChangeLog:

	* gdb/ChangeLog:
	* gdb/Makefile.in:
	* gdb/dwarf2/read.c (dwarf_tag_name):
	(dwarf_attr_name):
	(dwarf_form_name):
	(dwarf_bool_name):
	(dwarf_type_encoding_name):
	(dwarf_unknown):
	* gdb/dwarf2/stringify.c: New file.
	* gdb/dwarf2/stringify.h: New file.

> 
> Martin> About the merges: it's a pain to make a backport (a.k.a) as you're very likely
> Martin> conflict in ChangeLog entries. Having the ChangeLog entries in message one
> Martin> can do simple git cherry-pick and it's done.
> 
> This is emphatically not the case for me.
> 
> Martin> About the date-updating: it's also pain to always update a timestamp before
> Martin> a patch is installed.
> 
> What I'm saying is that it isn't a pain.  It's a single command before
> pushing.  I can't remember the last time the scripts failed but it's
> surely been more than 5 years.
> 
> I write a lot of patches in gdb and I have already filed off as many
> annoying parts as I could -- which is why my default stance is not to
> want to change.  Changing implies that maybe I'd have to redo this work.

Sure. You're a skilled GDB developer with long experience. But for newcomers or
people without the scripts, this can simplify their workflow.

Martin

> 
> Tom
> 

RE: Auto update ChangeLog for binutils+gdb commits?

[Aktemur, Tankut Baris]

On Friday, May 29, 2020 3:57 PM, Martin Liška wrote:
>
> $ git format-patch -1 2b2558bfacba3813863da6728c021eb89fa34677 && ~/Programming/gcc/contrib/mklog.py 00*
> 0001-Move-DWARF-constant-stringifying-code-to-new-file.patch
> 
> ChangeLog:
> 
> 	* gdb/ChangeLog:
> 	* gdb/Makefile.in:
> 	* gdb/dwarf2/read.c (dwarf_tag_name):
> 	(dwarf_attr_name):
> 	(dwarf_form_name):
> 	(dwarf_bool_name):
> 	(dwarf_type_encoding_name):
> 	(dwarf_unknown):
> 	* gdb/dwarf2/stringify.c: New file.
> 	* gdb/dwarf2/stringify.h: New file.

Is this actually correct?  I think it should have been

gdb/

	* Makefile.in:
	* dwarf2/read.c (dwarf_tag_name):

... and so on.

-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/30/20 12:23 PM, Aktemur, Tankut Baris wrote:
> Is this actually correct?  I think it should have been
> 
> gdb/
> 
> 	* Makefile.in:
> 	* dwarf2/read.c (dwarf_tag_name):
> 
> ... and so on.

Yes, I forgot to change directory root from gcc to binutils:

$ git format-patch -1 2b2558bfacba3813863da6728c021eb89fa34677 && ~/Programming/gcc/contrib/mklog.py 00*
0001-Move-DWARF-constant-stringifying-code-to-new-file.patch
gdb/ChangeLog:

	* ChangeLog:
	* Makefile.in:
	* dwarf2/read.c (dwarf_tag_name):
	(dwarf_attr_name):
	(dwarf_form_name):
	(dwarf_bool_name):
	(dwarf_type_encoding_name):
	(dwarf_unknown):
	* dwarf2/stringify.c: New file.
	* dwarf2/stringify.h: New file.

Martin

Re: Auto update ChangeLog for binutils+gdb commits?

[Tom Tromey]

>> Could you run it on some recent gdb commits and show the output?

I tried it out a little as well.

It seems promising.  However, I noticed some issues.

First, in the basic output:

Martin> 	* gdb/Makefile.in:

It would be more convenient for editing if the ":" were followed by a
space, since I'm normally going to have to add one anyway.


Next, try it like:

$ git show af0b2a3e85df9f49a3528e5b7578fcf9412f1acc | ./contrib/mklog.py

I get:

    gdb/ChangeLog:

            * ChangeLog:
            * dwarf2/abbrev.c (hash_abbrev):
            (abbrev_table::add_abbrev):
            (struct abbrev_info):
            (abbrev_table::lookup_abbrev):
            (abbrev_table::read):
            * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):
            (struct abbrev_table):

abbrev.c says:

            (struct abbrev_info):

... but I didn't see anything that would be relevant in the patch.

abbrev.h says:

            * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):

... but this is very incorrect.  In gdb we normally ignore changes to
the #includes, but if needed I suppose this could mention the addition
of one; but either way mentioning the include guard name is wrong --
macros should be ignored unless each preceding line ends with a
backslash.

If you try 89bcba74f89baceba3fa7387622e3d60e1de02e8, you'll see that
mklog ignores namespaces.

Martin> Sure. You're a skilled GDB developer with long experience. But for newcomers or
Martin> people without the scripts, this can simplify their workflow.

IMO we should optimize for reducing the overhead for regular
contributors.  Newcomers normally have many things to learn.

Tom

Re: Auto update ChangeLog for binutils+gdb commits?

[Fangrui Song]

I tried mklog.py on my gold patch.

% ~/Dev/gcc/contrib/mklog.py < 0001-gold-Set-DF_1_PIE-for-pie.patch
ChangeLog:

        * elfcpp/elfcpp.h (enum DF_1):
        * gold/layout.cc (Layout::finish_dynamic_section):

IIUC, the practice is to group ChangeLog's by the top-level directories

        elfcpp
        * elfcpp.h (enum DF_1):

        gold
        * layout.cc (Layout::finish_dynamic_section):

On Sat, May 30, 2020 at 12:41 PM Tom Tromey <tom@tromey.com> wrote:
>
> >> Could you run it on some recent gdb commits and show the output?
>
> I tried it out a little as well.
>
> It seems promising.  However, I noticed some issues.
>
> First, in the basic output:
>
> Martin>         * gdb/Makefile.in:
>
> It would be more convenient for editing if the ":" were followed by a
> space, since I'm normally going to have to add one anyway.
>
>
> Next, try it like:
>
> $ git show af0b2a3e85df9f49a3528e5b7578fcf9412f1acc | ./contrib/mklog.py
>
> I get:
>
>     gdb/ChangeLog:
>
>             * ChangeLog:
>             * dwarf2/abbrev.c (hash_abbrev):
>             (abbrev_table::add_abbrev):
>             (struct abbrev_info):
>             (abbrev_table::lookup_abbrev):
>             (abbrev_table::read):
>             * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):
>             (struct abbrev_table):
>
> abbrev.c says:
>
>             (struct abbrev_info):
>
> ... but I didn't see anything that would be relevant in the patch.
>
> abbrev.h says:
>
>             * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):
>
> ... but this is very incorrect.  In gdb we normally ignore changes to
> the #includes, but if needed I suppose this could mention the addition
> of one; but either way mentioning the include guard name is wrong --
> macros should be ignored unless each preceding line ends with a
> backslash.
>
> If you try 89bcba74f89baceba3fa7387622e3d60e1de02e8, you'll see that
> mklog ignores namespaces.
>
> Martin> Sure. You're a skilled GDB developer with long experience. But for newcomers or
> Martin> people without the scripts, this can simplify their workflow.
>
> IMO we should optimize for reducing the overhead for regular
> contributors.  Newcomers normally have many things to learn.
>
> Tom

Re: Auto update ChangeLog for binutils+gdb commits?

[Jan Vrany]

On Sat, 2020-05-30 at 13:41 -0600, Tom Tromey wrote:
> > > 
> IMO we should optimize for reducing the overhead for regular
> contributors.  Newcomers normally have many things to learn.

Being a newcomer, here's my perspective: 

I must admit that dealing with changelogs
(editing them, fixing them, making sure both changelog in
file and in commit message are in sync) is a significant portion
of the time. Fixing / improving the code is usually ~20% of the total
time in my case (another time-consumer are tests, that's different story). 
Indeed, I might be exception. 

That being said, this is the highest "overhead" of all projects I work
on - not many, though. 

My 2c. 

Jan

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/30/20 9:41 PM, Tom Tromey wrote:
>>> Could you run it on some recent gdb commits and show the output?
> 
> I tried it out a little as well.
> 
> It seems promising.  However, I noticed some issues.
> 
> First, in the basic output:
> 
> Martin> 	* gdb/Makefile.in:
> 
> It would be more convenient for editing if the ":" were followed by a
> space, since I'm normally going to have to add one anyway.

Yes, that would be very easy to add.

> 
> 
> Next, try it like:
> 
> $ git show af0b2a3e85df9f49a3528e5b7578fcf9412f1acc | ./contrib/mklog.py
> 
> I get:
> 
>      gdb/ChangeLog:
> 
>              * ChangeLog:
>              * dwarf2/abbrev.c (hash_abbrev):
>              (abbrev_table::add_abbrev):
>              (struct abbrev_info):
>              (abbrev_table::lookup_abbrev):
>              (abbrev_table::read):
>              * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):
>              (struct abbrev_table):
> 
> abbrev.c says:
> 
>              (struct abbrev_info):
> 
> ... but I didn't see anything that would be relevant in the patch.
> 
> abbrev.h says:
> 
>              * dwarf2/abbrev.h (GDB_DWARF2_ABBREV_H):
> 
> ... but this is very incorrect.  In gdb we normally ignore changes to
> the #includes, but if needed I suppose this could mention the addition
> of one; but either way mentioning the include guard name is wrong --
> macros should be ignored unless each preceding line ends with a
> backslash.

You are right, there are limitations, one of the reasons is that GCC
requires a return function type to be on a separate line from function name.

> 
> If you try 89bcba74f89baceba3fa7387622e3d60e1de02e8, you'll see that
> mklog ignores namespaces.

Yes, it's missing right now.

Martin

> 
> Martin> Sure. You're a skilled GDB developer with long experience. But for newcomers or
> Martin> people without the scripts, this can simplify their workflow.
> 
> IMO we should optimize for reducing the overhead for regular
> contributors.  Newcomers normally have many things to learn.
> 
> Tom
> 

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/29/20 2:15 PM, Tom Tromey wrote:
> merges, rebases, and date-updating; and Emacs provides direct support

About the date-updating: it's also pain to always update a timestamp before
a patch is installed. We recommend not using an author line and datestamp and
both these information can be taken from a git commit.

Martin

Re: Auto update ChangeLog for binutils+gdb commits?

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Date: Fri, 29 May 2020 06:15:01 -0600
> Cc: Simon Marchi <simark@simark.ca>, "H.J. Lu" <hjl.tools@gmail.com>,
>  Binutils <binutils@sourceware.org>, GDB <gdb@sourceware.org>
> 
> I'd also be open to changing the format to something requiring zero
> manual intervention.  For example, if we could have a commit script that
> simply listed the files and didn't require editing in the names of the
> functions.

Having the names of the functions in the log is one of the most
important reasons for following the ChangeLog format.  If it were not
for that reason, we could let people write free-text log messages,
because file names are easily gleaned from the VCS log.

Re: Auto update ChangeLog for binutils+gdb commits?

[Tom Tromey]

Eli> Having the names of the functions in the log is one of the most
Eli> important reasons for following the ChangeLog format.  If it were not
Eli> for that reason, we could let people write free-text log messages,
Eli> because file names are easily gleaned from the VCS log.

If the mklog script works, then the function names are also easily
computed from the diff.

Tom

Re: Auto update ChangeLog for binutils+gdb commits?

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  mliska@suse.cz,  simark@simark.ca,
>   hjl.tools@gmail.com,  binutils@sourceware.org,  gdb@sourceware.org
> Date: Sat, 30 May 2020 13:23:57 -0600
> 
> Eli> Having the names of the functions in the log is one of the most
> Eli> important reasons for following the ChangeLog format.  If it were not
> Eli> for that reason, we could let people write free-text log messages,
> Eli> because file names are easily gleaned from the VCS log.
> 
> If the mklog script works, then the function names are also easily
> computed from the diff.

If all the script does is look at the hunk headers of the diffs, then
indeed such a script doesn't have any added value.  I thought it did a
more thorough (and thus more accurate) job than that.

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 5/30/20 9:35 PM, Eli Zaretskii wrote:
>> From: Tom Tromey <tom@tromey.com>
>> Cc: Tom Tromey <tom@tromey.com>,  mliska@suse.cz,  simark@simark.ca,
>>    hjl.tools@gmail.com,  binutils@sourceware.org,  gdb@sourceware.org
>> Date: Sat, 30 May 2020 13:23:57 -0600
>>
>> Eli> Having the names of the functions in the log is one of the most
>> Eli> important reasons for following the ChangeLog format.  If it were not
>> Eli> for that reason, we could let people write free-text log messages,
>> Eli> because file names are easily gleaned from the VCS log.
>>
>> If the mklog script works, then the function names are also easily
>> computed from the diff.
> 
> If all the script does is look at the hunk headers of the diffs, then
> indeed such a script doesn't have any added value.  I thought it did a
> more thorough (and thus more accurate) job than that.
> 

It does, it tries to find a function name, macro, struct in a diff hunk
and this name is taken as changed. If nothing like this is found, then
diff header name is used.

Martin

Re: Auto update ChangeLog for binutils+gdb commits?

[Eli Zaretskii]

> Cc: simark@simark.ca, hjl.tools@gmail.com, binutils@sourceware.org,
>  gdb@sourceware.org
> From: Martin Liška <mliska@suse.cz>
> Date: Mon, 1 Jun 2020 09:39:08 +0200
> 
> > If all the script does is look at the hunk headers of the diffs, then
> > indeed such a script doesn't have any added value.  I thought it did a
> > more thorough (and thus more accurate) job than that.
> > 
> 
> It does, it tries to find a function name, macro, struct in a diff hunk
> and this name is taken as changed. If nothing like this is found, then
> diff header name is used.

How does it handle the frequent case where the change is attributed by
Diff to the previous function because the function's type or argument
list is being modified?

And how does the script decide that "nothing like this is found",
i.e. how does it know that what is in the hunk header is not really a
function name?

Thanks.

Re: Auto update ChangeLog for binutils+gdb commits?

[Martin Liška]

On 6/1/20 4:59 PM, Eli Zaretskii wrote:
>> Cc: simark@simark.ca, hjl.tools@gmail.com, binutils@sourceware.org,
>>   gdb@sourceware.org
>> From: Martin Liška <mliska@suse.cz>
>> Date: Mon, 1 Jun 2020 09:39:08 +0200
>>
>>> If all the script does is look at the hunk headers of the diffs, then
>>> indeed such a script doesn't have any added value.  I thought it did a
>>> more thorough (and thus more accurate) job than that.
>>>
>>
>> It does, it tries to find a function name, macro, struct in a diff hunk
>> and this name is taken as changed. If nothing like this is found, then
>> diff header name is used.
> 
> How does it handle the frequent case where the change is attributed by
> Diff to the previous function because the function's type or argument
> list is being modified?

It's handled by parsing of each diff line where we try to identify
beginning of a function, strut or something else. In that case the
diff header is ignored.

> 
> And how does the script decide that "nothing like this is found",
> i.e. how does it know that what is in the hunk header is not really a
> function name?

It's best effort approach and it's not easy task ;)

Martin

> 
> Thanks.
> 

Re: Auto update ChangeLog for binutils+gdb commits?

[Fangrui Song]

On Mon, Jun 1, 2020 at 11:49 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 6/1/20 4:59 PM, Eli Zaretskii wrote:
> >> Cc: simark@simark.ca, hjl.tools@gmail.com, binutils@sourceware.org,
> >>   gdb@sourceware.org
> >> From: Martin Liška <mliska@suse.cz>
> >> Date: Mon, 1 Jun 2020 09:39:08 +0200
> >>
> >>> If all the script does is look at the hunk headers of the diffs, then
> >>> indeed such a script doesn't have any added value.  I thought it did a
> >>> more thorough (and thus more accurate) job than that.
> >>>
> >>
> >> It does, it tries to find a function name, macro, struct in a diff hunk
> >> and this name is taken as changed. If nothing like this is found, then
> >> diff header name is used.
> >
> > How does it handle the frequent case where the change is attributed by
> > Diff to the previous function because the function's type or argument
> > list is being modified?
>
> It's handled by parsing of each diff line where we try to identify
> beginning of a function, strut or something else. In that case the
> diff header is ignored.
>
> >
> > And how does the script decide that "nothing like this is found",
> > i.e. how does it know that what is in the hunk header is not really a
> > function name?
>
> It's best effort approach and it's not easy task ;)
>
> Martin
>
> >
> > Thanks.
> >
>

Seems that ChangeLog files in binutils and gdb are still being
modified manually.

See glibc tag changelog-ends-here. They stopped updating ChangeLog
files manually.