http://sourceware.org/bugzilla/show_bug.cgi?id=14768
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #11 from Alan Modra <amodra at gmail dot com> ---
Can I suggest a commit log policy change when we switch to git? Something
like:
The commit log should generally consist of the subject line in your mailing
list patch submission, followed by the url of the patch, the explanatory text
you wrote in that email, and optionally, the ChangeLog entry for your patch.
Do *not* include the actual patch in the log message! For example, here is one
I wrote for a glibc patch.
PowerPC SIGSTKSZ
http://sourceware.org/ml/libc-alpha/2013-08/msg00093.html
This copies the sparc version of sigstack.h, which gives powerpc
#define MINSIGSTKSZ 4096
#define SIGSTKSZ 16384
Before the VSX changes, struct rt_sigframe size was 1920 plus 128 for
__SIGNAL_FRAMESIZE giving ppc64 exactly the default MINSIGSTKSZ of
2048.
After VSX, ucontext increased by 256 bytes. Oops, we're over
MINSIGSTKSZ, so powerpc has been using the wrong value for quite a
while. Add another ucontext for TM and rt_sigframe is now at 3872,
giving actual MINSIGSTKSZ of 4000.
The glibc testcase that I was looking at was tst-cancel21, which
allocates 2*SIGSTKSZ (not because the test is trying to be
conservative, but because the test actually has nested signal stack
frames). We blew the allocation by 48 bytes when using current
mainline gcc to compile glibc (le ppc64).
The required stack depth in _dl_lookup_symbol_x from the top of the
next signal frame was 10944 bytes. I guess you'd want to add 288 to
that, implying an actual SIGSTKSZ of 11232.
The subject should be on a line by itself and not exceed 75 characters. You
should have chosen a subject that was a reasonable summary of your patch when
writing your patch submission. This helps the relevant maintainer notice your
patch, and helps people searching for a bug fix. We ask for this in the commit
log too, because a number of tools display the first line of git commit logs.
The url of your patch allows people to easily find discussion related to your
patch.
The explanatory text is there in the commit log to aid people working with the
sources offline. The ChangeLog entry in the commit log is optional except when
you did not include explanatory text in your patch submission, which might be
reasonable if the ChangeLog entry is self-explanatory.
There are of course exceptions to these rules. For example, a single line
commit log saying "regenerate configure" is acceptable if that is all you are
doing.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
