From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8575 invoked by alias); 16 May 2012 14:45:54 -0000 Received: (qmail 8492 invoked by uid 22791); 16 May 2012 14:45:52 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 14:45:37 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SUfTr-0002RB-On from Maciej_Rozycki@mentor.com ; Wed, 16 May 2012 07:45:35 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 07:45:35 -0700 Received: from [172.30.0.201] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.1.289.1; Wed, 16 May 2012 15:45:33 +0100 Date: Wed, 16 May 2012 14:45:00 -0000 From: "Maciej W. Rozycki" To: Jan Kratochvil CC: Tom Tromey , , Sergio Durigan Subject: Re: [RFA] MIPS16 FP manual call/return fixes In-Reply-To: <20120514115338.GA14436@host2.jankratochvil.net> Message-ID: References: <87mx5y70mv.fsf@fleche.redhat.com> <20120501140457.GA1691@host2.jankratochvil.net> <20120502212811.GA22285@host2.jankratochvil.net> <20120512193750.GA26427@host2.jankratochvil.net> <20120514115338.GA14436@host2.jankratochvil.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2012-05/txt/msg00606.txt.bz2 On Mon, 14 May 2012, Jan Kratochvil wrote: > > strictly speaking we can keep the structure flat if > > we decide that complicating it is not worth the saving. > > Technically yes but it is more readable to know this field is valid/used only > with this subclass. And it is better not just to rely on unstructured > comments content. And to give the field name its real meaning ("func_addr") > and not just a generic name of overload ("related"). A good example of these > overloaded generic fields without subclassing is main_type which is such as > mess I still have problems to fully understand it. Yes, I can't disagree, common sense applies. > > Actually, I relied on the lack of compilation errors so far; it seems > > that while we do have -Wall -Werror, we have -Wno-unused as well which > > implies -Wno-unused-variable and has defeated my assumptions. Any > > particular reason why we disable this warning? > > Because there are now many such unused-variable cases needing to be fixed, > there were recent threads about it (see subject /unused/) by Sergio. > It looks still not all the cases are fixed to enable the warnings. Hmm, fair enough, I wonder if we could take -Wno-unused out in the maintainer's mode so as to prompt people to fix their bugs? > > > > b->type = bp_gnu_ifunc_resolver; > > > > > > Empty line before a comment according to GDB Coding Standards. > > > > > > > + /* Remember the resolver's address for use by the return > [...] > > I believe this requirement applies to function and variable/type/etc. > > definitions only and I haven't seen this style applied inline in many > > places (including the original comment above, actually). Are you sure? > > I find it more readable with the empty line even in this case. > You are right there are too many of such cases without empty line in GDB. > Therefore I do not mind, check it in either way. I think common sense applies again, I often find these extra empty lines disturbing with small comments, but larger ones definitely do need this extra space so that they do not obscure actual code. Anyway, 48 hours have passed with no further comments, so I have committed this change now, as posted. If anything that was missed by chance pops out, then we can address it with a follow-up change. Thanks to everybody involved. Maciej