Re: Patches submission policy change
Mark Wielaard writes: Hello Mark! > gcc-patches, binutils and gdb-patches all have only one moderator > (Jeff, Ian and Thiago). It would probably be good if there were > more. > > Any volunteers? It shouldn't be more than 1 to 3 emails a week > (sadly most of them spam). If still needed, I volunteer for the gcc list! Marc
Modifying GCC source code
Hello! I am trying to slightly modify the source code of GCC to display some messages when the compiler is executed in the terminal. For example, when 'gcc source.c' is executed, I want a print message saying "Building with GCC..." and if the build is successful, "Build Successful!" should be displayed otherwise "Build Failed!" should be displayed. I have tried adding the print statements in the driver code file (gcc.cc) but haven't had any success. Adding the print statement in driver::main function breaks everything and the code doesn't even build. I have tried adding the print statements in all the major methods in the driver code such as, driver::execute, driver::finalize, driver::init_spec, driver::main, etc but the result that I get is that either the code breaks while building the GCC from source, or it builds successfully but the print statements do not get displayed. I'm uncertain how to proceed. Any guidance on how to begin and what files or functions I need to check out would be greatly appreciated. Thanks in advance!
gcc-11-20240404 is now available
Snapshot gcc-11-20240404 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240404/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 239728ffd579e4947c9f9932ccea8a4801b58800 You'll find: gcc-11-20240404.tar.xz Complete GCC SHA256=26e7459e8e1d9c48242710014da5e9ffe2023a7619e84c7f20f732402ea4f48b SHA1=71ced925019fd8ff4401633e027d4dcabd25f082 Diffs from 11-20240328 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Patches submission policy change
On 2024-04-04 17:35, Mark Wielaard wrote: > Hi Christophe, > > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote: >> TL;DR: For the sake of improving precommit CI coverage and simplifying >> workflows, I’d like to request a patch submission policy change, so >> that we now include regenerated files. This was discussed during the >> last GNU toolchain office hours meeting [1] (2024-03-28). >> >> Benefits or this change include: >> - Increased compatibility with precommit CI >> - No need to manually edit patches before submitting, thus the “git >> send-email” workflow is simplified >> - Patch reviewers can be confident that the committed patch will be >> exactly what they approved >> - Precommit CI can test exactly what has been submitted >> >> Any concerns/objections? > > I am all for it. It will make testing patches easier for everyone. > > I do think we still need a better way to make sure all generated files > can be regenerated. If only to check that the files were generated > correctly with the correct versions. The autoregen buildbots are able > to catch some, but not all such mistakes. > > wrt to the mailinglists maybe getting larger patches, I think most > will still be under 400K and I wouldn't raise the limit (because most > such larger emails are really just spam). But we might want to get > more mailinglist moderators. > > gcc-patches, binutils and gdb-patches all have only one moderator > (Jeff, Ian and Thiago). It would probably be good if there were > more. > > Any volunteers? It shouldn't be more than 1 to 3 emails a week > (sadly most of them spam). I can help with the various gdb mailing lists. Simon
Re: Patches submission policy change
Hi Christophe, On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote: > TL;DR: For the sake of improving precommit CI coverage and simplifying > workflows, I’d like to request a patch submission policy change, so > that we now include regenerated files. This was discussed during the > last GNU toolchain office hours meeting [1] (2024-03-28). > > Benefits or this change include: > - Increased compatibility with precommit CI > - No need to manually edit patches before submitting, thus the “git > send-email” workflow is simplified > - Patch reviewers can be confident that the committed patch will be > exactly what they approved > - Precommit CI can test exactly what has been submitted > > Any concerns/objections? I am all for it. It will make testing patches easier for everyone. I do think we still need a better way to make sure all generated files can be regenerated. If only to check that the files were generated correctly with the correct versions. The autoregen buildbots are able to catch some, but not all such mistakes. wrt to the mailinglists maybe getting larger patches, I think most will still be under 400K and I wouldn't raise the limit (because most such larger emails are really just spam). But we might want to get more mailinglist moderators. gcc-patches, binutils and gdb-patches all have only one moderator (Jeff, Ian and Thiago). It would probably be good if there were more. Any volunteers? It shouldn't be more than 1 to 3 emails a week (sadly most of them spam). Cheers, Mark
Re: Sourceware mitigating and preventing the next xz-backdoor
Hello, On Wed, 3 Apr 2024, Jonathon Anderson wrote: > Of course, this doesn't make the build system any less complex, but > projects using newer build systems seem easier to secure and audit than > those using overly flexible build systems like Autotools and maybe even > CMake. IMHO using a late-model build system is a relatively low > technical hurdle to overcome for the benefits noted above, switching > should be considered and in a positive light. Note that we're talking not (only) about the build system itself, i.e. how to declare dependencies within the sources, and how to declare how to build them. make it just fine for that (as are many others). (In a way I think we meanwhile wouldn't really need automake and autogen, but rewriting all that in pure GNUmake is a major undertaking). But Martin also specifically asked about alternatives for feature tests, i.e. autoconfs purpose. I simply don't see how any alternative to it could be majorly "easier" or "less complex" at its core. Going with the examples given upthread there is usually only one major solution: to check if a given system supports FOOBAR you need to bite the bullet and compile (and potentially run!) a small program using FOOBAR. A configuration system that can do that (and I don't see any real alternative to that), no matter in which language it's written and how traditional or modern it is, also gives you enough rope to hang yourself, if you so choose. If you get away without many configuration tests in your project then this is because what (e.g.) the compiler gives you, in the form of libstdc++ for example, abstracts away many of the peculiarities of a system. But in order to be able to do that something (namely the config system of libstdc++) needs to determine what is or isn't supported by the system in order to correctly implement these abstractions. I.e. things you depend on did the major lifting of hiding system divergence. (Well, that, or you are very limited in the number of systems you support, which can be the right thing as well!) Ciao, Michael.
Re: Sourceware mitigating and preventing the next xz-backdoor
Hi, On Wed, 2024-04-03 at 08:42 -0600, Jeff Law wrote: > On 4/3/24 8:04 AM, Tom Tromey wrote: > > > > > > > "Florian" == Florian Weimer writes: > > > > Florian> Everyone still pushes their own patches, and there are no > > Florian> technical countermeasures in place to ensure that the pushed > > version is > > Florian> the reviewed version. > > > > This is a problem for gdb as well. > > > > Probably we should switch to some kind of pull-request model, where > > patches can only be landed via the UI, after sufficient review; and > > where all generated files are regenerated by the robot before checkin. > > (Or alternatively some CI runs and rejects patches where they don't > > match.) > I've very much prefer to move to a pull-request model. Do you need any infrastructure updates to help (experiment) with that? Now would be a great time to request some updates to patchwork or get us to resurrect the gerrit server if that would be helpful. We just published the Sourceware 2024 infrastructure plan: https://inbox.sourceware.org/20240325095827.gi5...@gnu.wildebeest.org/ Setting priorities for the infrastructure for 2024 (and beyond). We are just now scheduling and budgeting that work. So please get your requests in. Cheers, Mark
Re: Sourceware mitigating and preventing the next xz-backdoor
Hi, On Wed, 2024-04-03 at 08:53 -0500, Joel Sherrill wrote: > On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb > wrote: > > * Guinevere Larsen via Overseers: > > > > > Beyond that, we (GDB) are already experimenting with approved-by, and > > > I think glibc was doing the same. > > > > The glibc project uses Reviewed-by:, but it's completely unrelated to > > this. Everyone still pushes their own patches, and there are no > > technical countermeasures in place to ensure that the pushed version is > > the reviewed version. > > Or that there isn't "collusion" between a malicious author and reviewer. > Just tagging it approved or reviewed by just gives you two people to blame. > It is not a perfect solution either. > > But double checking and checklists are good practices. > They are not foolproof if some bad actor is determined enough. Agreed. If you just focus on completely fool proof technically checkable measures then you end up doing nothing. But making things like always getting a Reviewed-by or Tested-by tag in your commit message does strengthen the social norms. And once they are common practice you could even add some technical checks. I am sure a really determined bad actor can always find some social or technical engineering trick to "defeat" our project policies. But that doesn't mean we shouldn't do things which are good practices anyway. Cheers, Mark
Re: Patches submission policy change
On 03.04.2024 15:11, Christophe Lyon wrote: > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: >> >> On 03.04.2024 10:22, Christophe Lyon wrote: >>> Dear release managers and developers, >>> >>> TL;DR: For the sake of improving precommit CI coverage and simplifying >>> workflows, I’d like to request a patch submission policy change, so >>> that we now include regenerated files. This was discussed during the >>> last GNU toolchain office hours meeting [1] (2024-03-28). >>> >>> Benefits or this change include: >>> - Increased compatibility with precommit CI >>> - No need to manually edit patches before submitting, thus the “git >>> send-email” workflow is simplified >>> - Patch reviewers can be confident that the committed patch will be >>> exactly what they approved >>> - Precommit CI can test exactly what has been submitted >>> >>> Any concerns/objections? >> >> Yes: Patch size. And no, not sending patches inline is bad practice. > Not sure what you mean? Do you mean sending patches as attachments is > bad practice? Yes. It makes it difficult to reply to them (with proper reply context). >> Even assuming sending patches bi-modal (inline and as attachment) works >> (please indicate whether that's the case), it would mean extra work on >> the sending side. >> > For the CI perspective, we use what patchwork is able to detect as patches. > Looking at recent patches submissions, it seems patchwork is able to > cope with the output of git format-patch/git send-email, as well as > attachments. > There are cases where patchwork is not able to detect the patch, but I > don't know patchwork's exact specifications. Question was though: If a patch was sent inline plus attachment, what would CI use as the patch to apply? IOW would it be an option to attach the un-stripped patch, while inlining the stripped one? Jan
