From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41370 invoked by alias); 8 Apr 2015 16:47:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 41360 invoked by uid 89); 8 Apr 2015 16:47:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Apr 2015 16:47:11 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4FC9AAB110; Wed, 8 Apr 2015 16:47:10 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t38Gl874025494; Wed, 8 Apr 2015 12:47:08 -0400 Message-ID: <55255B8B.40003@redhat.com> Date: Wed, 08 Apr 2015 16:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi CC: Pierre Muller , "'Sergio Durigan Junior'" , "'GDB Patches'" Subject: Re: Build failure following: Implement support for checking /proc/PID/coredump_filter commit References: <1427241443-5939-1-git-send-email-sergiodj@redhat.com> <1427241443-5939-2-git-send-email-sergiodj@redhat.com> <5515289D.1000006@redhat.com> <874mp0vir0.fsf@redhat.com> <000001d07205$69de1770$3d9a4650$@muller@ics-cnrs.unistra.fr> <55253E9E.4060106@redhat.com> <86egnuwpoj.fsf@gmail.com> In-Reply-To: <86egnuwpoj.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00277.txt.bz2 On 04/08/2015 05:27 PM, Yao Qi wrote: > Pedro Alves writes: > >> There's also the "users/palves/gnulib-update" branch that >> updates gdb's copy of gnulib to recent gnulib master. It'd >> be great if someone confirmed that a gdb build of that branch >> actually works on Windows, so we can move forward with that. >> (the branch predates Sergio's patch, so isn't affected by the strtok_r >> issue). I'd be nice to update our gnulib copy before we pull in >> more modules, to avoid tripping on bugs that have meanwhile already >> been fixed upstream, or avoid module dependencies that may >> have been reduced upstream... > > On the other hand, updating our gnulib copy from upstream may introduce > new bugs. Sure. And we can report and fix them, or downgrade a few revisions to before when the bug was introduced. > strtok_r exists in the gnulib > 8d5bd1402003bd0153984b138735adf537d960b0 commit we are using, I don't That's actually what I did in the branch I pointed Pierre at. > see why we need to update our gnulib copy, unless there are some known > bug fixes in gnulib upstream. Why risk stumbling on bugs that might have been fixed in the 3 years since the last import? The more modules we import off the older copy, the wider the potential-bugs surface. And then what to do if we need to patch gnulib? If the requirement is to send the fix upstream first, and then refresh our import, it'll be much easier if the re-import is just a small incremental update, rather than pulling in multiple years of gnulib work. The further apart our update is, the harder it is to update. If we keep our copy reasonably up to date, we have a better chance of whoever introduced the bug upstream to still have the issue fresh in mind and provide a prompt fix. If we wait 3 years to report a bug, then the chances are good that we get to fix it ourselves. I currently want to update gnulib for at least 3 reasons: - GDB-in-C++ on mingw: https://sourceware.org/ml/gdb-patches/2015-03/msg00447.html That will have to be fixed on gnulib. Haven't checked if already fixed there, but most probably it is. - Antoine's use of canonicalize: https://sourceware.org/ml/gdb-patches/2015-03/msg00917.html That pulls in a truck load of modules. I'd hope the dependencies are fewer in a newer gnulib, or at least, if the dependencies are the same, I'd much prefer importing up-to-date versions. Otherwise, the poor soul that next updates gnulib is likely to have a "fun" time. - Pull in the fts module to get rid of the "system" call in compile/, as discussed a while ago. I think now's the best time, as we still have time till the next gdb release. Thanks, Pedro Alves