Re: GCC's instrumentation and the target environment
On 11/1/19 7:13 PM, David Taylor wrote: I wish to use GCC based instrumentation on an embedded target. And I am finding that GCC's libgcov.a is not well suited to my needs. Ideally, all the application entry points and everthing that knows about the internals of the implementation would be in separate files from everything that does i/o or otherwise uses 'system services'. Right now GCC has libgcov-driver.c which includes both gcov-io.c and libgcov-driver-system.c. Hello. What I'd like is a stable API between the routines that 'collect' the data and the routines that do the i/o. With the i/o routines being non-static and in a separate file from the others that is not #include'd. I want them to be replaceable by the application. Depending upon circumstances I can imagine the routines doing network i/o, disk i/o, or using a serial port. What's difference in between i/o and disk i/o? What about using a NFS file system into which you can save the data (via -fprofile-dir=/mnt/mynfs/...)? I can imagine dump into stderr for example. That can be quite easily doable. Martin I want one version of libgcov.a for all three with three different sets of i/o routines that I can build into the application. If the internals of instrumentation changes, I want to not have to change the i/o routines or anything in the application. If you think of it in disk driver terms, some of the routines in libgcov.a provide a DDI -- an interface of routines that the application call call. For applications that exit, one of the routines is called at program exit. For long running applications, there are routines in the DDI to dump and flush the accumulated information. And the i/o routines can be thought of as providing a DKI -- what the library libgcov.a expects of the environment -- for example, fopen and fwrite. There's also the inhibit_libc define. While if you don't have headers you might have a hard time including or some of the other header files, if the environment has a way of doing i/o or saving the results, there is no real reason why it should not be possible to provide instrumentation. Comments?
Commit messages and the move to git
With the move to git fairly imminent now it would be nice if we could agree on a more git-friendly style of commit messages; and, ideally, start using them now so that the converted repository can benefit from this. Some tools, particularly gitk or git log --oneline, can use one-line summaries from a commit's log message when listing commits. It would be nice if we could start adopting a style that is compatible with this, so that in future commits are summarized in a useful way. Unfortunately, some of our existing commits show no useful information with tools like this. Eg. git log --oneline 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) 2019-11-01 Kewen Lin 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls 0f931fb75ae 2019-11-01 Kewen Lin e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays 377311a90fa 2019-11-01 Kewen Lin cc286dd8517 Daily bump. 8e87e30df8d Regenerate libstdc++ HTML docs fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE" d5e4b5a17de Partial implementation of C++20 of header 345d712f776 Test --help=common for full sentences a737cc23c15 PR preprocessor/92296 * internal.h (struct def_pragma_macro): Add is_builtin bitfield. (_cpp_restore_special_builtin): Declare.* init.c (_cpp_restore_special_builtin): New function. * directives.c (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and don't try to grab definition.(cpp_pop_definition): Use _cpp_restore_special_builtin to restore builtin macros. e9c843f92f6 2019-10-31 Jozef Lawrynowicz d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4* As you can see, some of these are useful and give a good summary of the patch, others only tell me who committed the patch, which is less than useful. In other cases almost the entire ChangeLog entry gets printed because there is no blank line to tell git where the end of the summary lies. The normal convention in git is that the one line summary is essentially the subject line of the email message that describes the patch and is then followed by a blank line before the body of the commit message. R.
Re: Commit messages and the move to git
> With the move to git fairly imminent now it would be nice if we > could agree on a more git-friendly style of commit messages; and, > ideally, start using them now so that the converted repository can > benefit from this. > > Some tools, particularly gitk or git log --oneline, can use one-line > summaries from a commit's log message when listing commits. It > would be nice if we could start adopting a style that is compatible > with this, so that in future commits are summarized in a useful way. > Unfortunately, some of our existing commits show no useful > information with tools like this. Strongly seconded. FWIW we've done that for a while in the gcc/ada directory already since we're using GIT internally on GCC and GNAT sources. Arno
Re: Commit messages and the move to git
On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote: > Some tools, particularly gitk or git log --oneline, can use one-line > summaries from a commit's log message when listing commits. It would be > nice if we could start adopting a style that is compatible with this, so > that in future commits are summarized in a useful way. ... > The normal convention in git is that the one line summary is essentially > the subject line of the email message that describes the patch and is > then followed by a blank line before the body of the commit message. > I wholeheartedly agree. Thanks to everyone already doing this and everyone else, please just start, adding a summary line takes just minimal effort. Martin
RE: GCC's instrumentation and the target environment
> From: Martin Liška > Sent: Monday, November 4, 2019 4:20 AM > To: taylor, david; gcc@gcc.gnu.org > Subject: Re: GCC's instrumentation and the target environment > On 11/1/19 7:13 PM, David Taylor wrote: > Hello. Hello. > > What I'd like is a stable API between the routines that 'collect' the > > data and the routines that do the i/o. With the i/o routines being > > non-static and in a separate file from the others that is not > > #include'd. > > > > I want them to be replaceable by the application. Depending upon > > circumstances I can imagine the routines doing network i/o, disk i/o, > > or using a serial port. > > What's difference in between i/o and disk i/o? What about using a NFS file > system into which you can save the data (via -fprofile-dir=/mnt/mynfs/...)? I/O encompasses more than just reading and writing a file in a file system. Depending on the embedded target you might not have the ability to NFS mount. You might not even have a file system accessible to instrumentation. By network I/O I'm thinking sockets. There's some code possibly run at 'boot' time or possibly run during the first __gcov_open that establishes a network connection with a process running on another system. There's some protocol, agreed to by the application and remote process, for communicating the data collected and which file it belongs to. By serial I/O, I'm thinking of a serial port. Hopefully that is clearer. > I can imagine dump into stderr for example. That can be quite easily doable. I don't think that the current implementation would make that easy. For us there are potentially over a thousand files being instrumented. You need to communicate which file the data belongs to. Whether it is via stderr, a serial port, or a network connection, the file name needs to be in the stream and there needs to be a way of determining when one file ends and the next one begins. For us, stderr and stdout, when defined, are used for communicating status and extraordinary events. And not well suited for transferring instrumentation data. > Martin David
Re: GCC's instrumentation and the target environment
On Mon, Nov 4, 2019 at 7:06 AM wrote: > > From: Martin Liška > > Sent: Monday, November 4, 2019 4:20 AM > > To: taylor, david; gcc@gcc.gnu.org > > Subject: Re: GCC's instrumentation and the target environment > > > On 11/1/19 7:13 PM, David Taylor wrote: > > > Hello. > > Hello. > > > > What I'd like is a stable API between the routines that 'collect' the > > > data and the routines that do the i/o. With the i/o routines being > > > non-static and in a separate file from the others that is not > > > #include'd. > > > > > > I want them to be replaceable by the application. Depending upon > > > circumstances I can imagine the routines doing network i/o, disk i/o, > > > or using a serial port. > > > > What's difference in between i/o and disk i/o? What about using a NFS > file > > system into which you can save the data (via > -fprofile-dir=/mnt/mynfs/...)? > > I/O encompasses more than just reading and writing a file in a file system. > Depending on the embedded target you might not have the ability to NFS > mount. > You might not even have a file system accessible to instrumentation. > > By network I/O I'm thinking sockets. There's some code possibly run at > 'boot' time or possibly run during the first __gcov_open that establishes a > network connection with > a process running on another system. There's some protocol, agreed to by > the > application and remote process, for communicating the data collected and > which > file it belongs to. > > By serial I/O, I'm thinking of a serial port. > > Hopefully that is clearer. > > > I can imagine dump into stderr for example. That can be quite easily > doable. > > I don't think that the current implementation would make that easy. For > us there > are potentially over a thousand files being instrumented. You need to > communicate > which file the data belongs to. Whether it is via stderr, a serial port, > or a network > connection, the file name needs to be in the stream and there needs to be > a way > of determining when one file ends and the next one begins. > > For us, stderr and stdout, when defined, are used for communicating > status and extraordinary events. And not well suited for transferring > instrumentation > data. > And I generally agree with that statement but I am also on a project evaluating the use of a commercial tool which does coverage and includes MCDC analysis. It has a very flexible plugin for this specific purpose. You can dump in any format you can decode to any output destination. They have many standard implementations and plenty of examples you can tailor. It wouldn't be terribly difficult to multiplex the console and filter it. I would suggest consideration for dumping into a buffer and having an external agent (e.g. debugger, JTAG based program, etc) retrieve it. RTEMS programs generally don't exit and often have no networking. You have to have flexibility. No one is forcing a singular output media -- just flexibility. I'd love to see decision and MCDC coverage support . --joel > > > Martin > > David > >
Re: Commit messages and the move to git
On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote: > With the move to git fairly imminent now it would be nice if we could > agree on a more git-friendly style of commit messages; and, ideally, > start using them now so that the converted repository can benefit from > this. > > Some tools, particularly gitk or git log --oneline, can use one-line > summaries from a commit's log message when listing commits. It would be > nice if we could start adopting a style that is compatible with this, so > that in future commits are summarized in a useful way. Unfortunately, > some of our existing commits show no useful information with tools like > this. I'd suggest we sync policy with glibc. They're further along on the ChangeLog issues. Whatever they do in this space we should follow -- aren't we going to be using some of their hooks/scripts? jeff
Re: Commit messages and the move to git
On 04/11/2019 16:04, Jeff Law wrote: On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote: With the move to git fairly imminent now it would be nice if we could agree on a more git-friendly style of commit messages; and, ideally, start using them now so that the converted repository can benefit from this. Some tools, particularly gitk or git log --oneline, can use one-line summaries from a commit's log message when listing commits. It would be nice if we could start adopting a style that is compatible with this, so that in future commits are summarized in a useful way. Unfortunately, some of our existing commits show no useful information with tools like this. I'd suggest we sync policy with glibc. They're further along on the ChangeLog issues. Whatever they do in this space we should follow -- aren't we going to be using some of their hooks/scripts? jeff I wouldn't object to that. But then, it's largely what I'm asking for, with a few minor details. https://sourceware.org/glibc/wiki/Contribution%20checklist#Contribution_Email_Subject_Line Seems to set out the rules. I think we'd probably want to keep PRn rather than switch to BZ #nn, but otherwise there's nothing I'd object to. It looks like, from a quick look at https://sourceware.org/ml/glibc-cvs/2019-q4/ that the email subject lines are largely what is used for the summary commits. R.
Re: Commit messages and the move to git
On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists) wrote: > > With the move to git fairly imminent now it would be nice if we could > agree on a more git-friendly style of commit messages; and, ideally, > start using them now so that the converted repository can benefit from this. > > Some tools, particularly gitk or git log --oneline, can use one-line > summaries from a commit's log message when listing commits. It would be > nice if we could start adopting a style that is compatible with this, so > that in future commits are summarized in a useful way. Unfortunately, > some of our existing commits show no useful information with tools like > this. > > Eg. > > git log --oneline > 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) > 2019-11-01 Kewen Lin > 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls > 0f931fb75ae 2019-11-01 Kewen Lin > e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran > allocatable/pointer arrays > 377311a90fa 2019-11-01 Kewen Lin > cc286dd8517 Daily bump. > 8e87e30df8d Regenerate libstdc++ HTML docs > fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE" > d5e4b5a17de Partial implementation of C++20 of header > 345d712f776 Test --help=common for full sentences > a737cc23c15 PR preprocessor/92296 * internal.h (struct > def_pragma_macro): Add is_builtin bitfield. > (_cpp_restore_special_builtin): Declare.* init.c > (_cpp_restore_special_builtin): New function. * directives.c > (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and > don't try to grab definition.(cpp_pop_definition): Use > _cpp_restore_special_builtin to restore builtin macros. > e9c843f92f6 2019-10-31 Jozef Lawrynowicz > d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C > ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4* > > As you can see, some of these are useful and give a good summary of the > patch, others only tell me who committed the patch, which is less than > useful. In other cases almost the entire ChangeLog entry gets printed > because there is no blank line to tell git where the end of the summary > lies. > > The normal convention in git is that the one line summary is essentially > the subject line of the email message that describes the patch and is > then followed by a blank line before the body of the commit message. I've already proposed a more specific format for libstdc++: https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
Re: Commit messages and the move to git
On 04/11/2019 16:19, Jonathan Wakely wrote: On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists) wrote: With the move to git fairly imminent now it would be nice if we could agree on a more git-friendly style of commit messages; and, ideally, start using them now so that the converted repository can benefit from this. Some tools, particularly gitk or git log --oneline, can use one-line summaries from a commit's log message when listing commits. It would be nice if we could start adopting a style that is compatible with this, so that in future commits are summarized in a useful way. Unfortunately, some of our existing commits show no useful information with tools like this. Eg. git log --oneline 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) 2019-11-01 Kewen Lin 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls 0f931fb75ae 2019-11-01 Kewen Lin e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays 377311a90fa 2019-11-01 Kewen Lin cc286dd8517 Daily bump. 8e87e30df8d Regenerate libstdc++ HTML docs fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE" d5e4b5a17de Partial implementation of C++20 of header 345d712f776 Test --help=common for full sentences a737cc23c15 PR preprocessor/92296 * internal.h (struct def_pragma_macro): Add is_builtin bitfield. (_cpp_restore_special_builtin): Declare.* init.c (_cpp_restore_special_builtin): New function. * directives.c (do_pragma_push_macro): For NT_BUILTIN_MACRO set is_builtin and don't try to grab definition.(cpp_pop_definition): Use _cpp_restore_special_builtin to restore builtin macros. e9c843f92f6 2019-10-31 Jozef Lawrynowicz d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4* As you can see, some of these are useful and give a good summary of the patch, others only tell me who committed the patch, which is less than useful. In other cases almost the entire ChangeLog entry gets printed because there is no blank line to tell git where the end of the summary lies. The normal convention in git is that the one line summary is essentially the subject line of the email message that describes the patch and is then followed by a blank line before the body of the commit message. I've already proposed a more specific format for libstdc++: https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html Well having additional requirements for a component on top of 'global' requirements doesn't pose a real problem as long as the maintainers of that component concur. Having incompatible requirements would be problematic, though. R.
Re: Fixing cvs2svn branchpoints
On Sat, 2 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > And here are corresponding lists of tags where the commit cvs2svn > > generated for the tag should be reparented. > > Make that issue 2, please. Done. > Also, open an issue 3 about how you want those > mid-branch deletes handled. I agree that the right thing is just to nuke > them, but I have a lot of plates in the air right now... Which mid-branch deletes? For the ones by accident (e.g. the deletions of trunk), where the branch was recreated by copying from the pre-deletion version of the same branch, nuking the deletes is clearly right. For the ones where a branch was deleted then recreated as a copy not from the deleted version - essentially, rebasing done in SVN - maybe we need community discussion of the right approach. (There are two plausible approaches there - either just discard all the deleted versions that aren't part of the SVN history of the most recent creation of the branch, which makes the list of commits in the branch's history in git look similar to what it looks like in SVN, or treat deletion + recreation in that case as some kind of merge.) > Also please open reposurgeon issues about the svnmerge properties As I understand it, support for that has now been implemented. > and the missing documentation. https://gitlab.com/esr/reposurgeon/issues/151 filed - it's a lot more than just reparent for which documentation appears to have disappeared. -- Joseph S. Myers jos...@codesourcery.com
Re: Commit messages and the move to git
On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > I've already proposed a more specific format for libstdc++: > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html PR libstdc++/12345 takes up the first 19 chars of the short subject, adding no useful information (unless the reader knows all PRs by heart, you need to look it up to know what it is). I usually put (PR12345) at the end of the subject. The area is clear from the rest of the subject already. Segher
Re: Commit messages and the move to git
On Mon, 4 Nov 2019, Segher Boessenkool wrote: > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > I've already proposed a more specific format for libstdc++: > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > adding no useful information (unless the reader knows all PRs by heart, > you need to look it up to know what it is). > > I usually put (PR12345) at the end of the subject. The area is clear > from the rest of the subject already. Agreed. (Hint to patch submitters: if the subject line of your patch submission is just "Fix PR12345" or similar, people are less likely to review your patch because nothing about the subject tells anyone that the patch is in their area and so something they should pay attention to. Patch submissions need to have subjects that make clear very quickly what the patch is about. This is also why I don't care for [PATCH] tags at the start of subject lines - they take away space for saying what the patch is about, and on gcc-patches we can expect things are patches, [PATCH] doesn't add useful information.) I've been using git-style commit messages in GCC for the past five years. -- Joseph S. Myers jos...@codesourcery.com
Re: Commit messages and the move to git
On Mon, Nov 04, 2019 at 01:43:17PM +0100, Martin Jambor wrote: > On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote: > > Some tools, particularly gitk or git log --oneline, can use one-line > > summaries from a commit's log message when listing commits. It would be > > nice if we could start adopting a style that is compatible with this, so > > that in future commits are summarized in a useful way. > > ... > > > The normal convention in git is that the one line summary is essentially > > the subject line of the email message that describes the patch and is > > then followed by a blank line before the body of the commit message. > > > > I wholeheartedly agree. Thanks to everyone already doing this and > everyone else, please just start, adding a summary line takes just > minimal effort. Making a good subject is work and takes time, just like making a good commit message, just like making a good patch. The effort is worth it for at least two reasons: 1) More people read the commit message than write it, and this balance shifts much further towards "read" if you consider the commit history instead of just the patch submissions. 2) Being forced to describe your patches often makes you find problems with them, or more generally, can make you actually understand what you are doing ;-) Segher
Re: Commit messages and the move to git
On Mon, Nov 04, 2019 at 05:42:47PM +, Joseph Myers wrote: > This is also why I don't care for [PATCH] tags at the > start of subject lines - they take away space for saying what the patch is > about, and on gcc-patches we can expect things are patches, [PATCH] > doesn't add useful information.) Yeah, but various tools automatically add them (and v2 and 1/4 etc. tags, which are extremely useful), so it would be very inconvenient to outlaw them. Oh, and it is what all of the rest of the world uses, I don't even consciously *see* the standard stuff anymore, it's only when people get creative ;-) Segher
Hello, I would like to know how to download gcc 9.2 in windows from here. https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/ Thanks.
Hello, I would like to know how to download gcc 9.2 in windows from here. https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/ Thanks.
Re: Commit messages and the move to git
Hi, on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote: > With the move to git fairly imminent now it would be nice if we could agree > on a more git-friendly style of commit messages; and, ideally, start using > them now so that the converted repository can benefit from this. > > Some tools, particularly gitk or git log --oneline, can use one-line > summaries from a commit's log message when listing commits. It would be nice > if we could start adopting a style that is compatible with this, so that in > future commits are summarized in a useful way. Unfortunately, some of our > existing commits show no useful information with tools like this. > > Eg. > > git log --oneline > 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) > 2019-11-01 Kewen Lin > 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls > 0f931fb75ae 2019-11-01 Kewen Lin > e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran > allocatable/pointer arrays > 377311a90fa 2019-11-01 Kewen Lin Sorry for the awful commit messages and thanks a lot for raising this up to stop me from stumbling continuously. I just updated all my svn commit comments by "svn propedit svn:log --revprop -r N --editor-cmd vim", but I guess it won't help any more if the upcoming git repo will come from some existing mirror? BR, Kewen
GCC 7 branch is frozen, all commits require release manager approval
The GCC 7 branch is now frozen for preparation of a release candidate for the final release from the branch, GCC 7.5. All commits require release manager approval from now on, ideally there will be no further commits to the branch since the branch will be closed after the GCC 7.5 release. Thanks for your understanding. Previous Report === https://gcc.gnu.org/ml/gcc/2019-10/msg00142.html
