From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23937 invoked by alias); 30 Sep 2009 11:18:36 -0000 Received: (qmail 23922 invoked by uid 22791); 30 Sep 2009 11:18:35 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp3.ugent.be (HELO smtp3.UGent.be) (157.193.49.127) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Sep 2009 11:18:31 +0000 Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.UGent.be (Postfix) with ESMTP id 49658147BBE; Wed, 30 Sep 2009 13:18:28 +0200 (CEST) Received: from smtp3.UGent.be ([157.193.49.127]) by localhost (mcheck2.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id Grs-eqekxcGB; Wed, 30 Sep 2009 13:18:27 +0200 (CEST) Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48]) by smtp3.UGent.be (Postfix) with ESMTP id 8A22E147BB0; Wed, 30 Sep 2009 13:18:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.elis.ugent.be (Postfix) with ESMTP id 555DC918F19; Wed, 30 Sep 2009 13:18:26 +0200 (CEST) Received: from mail.elis.ugent.be ([127.0.0.1]) by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHx-sPmaiwxm; Wed, 30 Sep 2009 13:18:23 +0200 (CEST) Received: from bigmac.elis.UGent.be (bigmac.elis.UGent.be [157.193.206.33]) by mail.elis.ugent.be (Postfix) with ESMTP id 1B731918F12; Wed, 30 Sep 2009 13:18:23 +0200 (CEST) Cc: tromey@redhat.com, Mark Kettenis , gdb-patches@sourceware.org Message-Id: <8F3B6095-4766-432D-ABB5-AB4DAA2D5572@elis.ugent.be> From: Jonas Maebe To: Joel Brobecker In-Reply-To: <20090930000225.GA10338@adacore.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [patch] Set calling convention of methods Date: Wed, 30 Sep 2009 11:18:00 -0000 References: <7B6EF4DA-76C8-4D9C-8B9F-94153EF1C4E1@elis.ugent.be> <691B0BA8-C606-42FF-A796-76CC9C31556A@elis.ugent.be> <200904222215.n3MMF0p2006994@brahms.sibelius.xs4all.nl> <19C107AA-5271-4C23-A6D2-AFF75BBAC4E4@elis.ugent.be> <5AA3BCA9-1ECF-446E-8B49-3132F0E470FB@elis.ugent.be> <20090930000225.GA10338@adacore.com> X-j-chkmail-Enveloppe: 4AC33E82.001/157.193.206.48/mail.elis.UGent.be/mail.elis.ugent.be/ X-j-chkmail-Score: MSGID : 4AC33E82.001 on smtp3.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham 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: 2009-09/txt/msg00946.txt.bz2 On 30 Sep 2009, at 02:02, Joel Brobecker wrote: >> I've attached my first patch. Other patches will modify code in this >> one, so I'd prefer to get this one out of the way first. > > But it looks like this patch actually introduces code that will be > dead > until you actually set the calling convention, right? It seems strange > that you'd prefer to do it this way. It will already be active for regular functions/procedures, because the DWARF reader does propagate the calling convention in that case (as it was already done for the DW_CC_GNU_renesas_sh calling convention). It simply won't be taken into account yet for methods (because that requires a patch to the DWARF reader), that will indeed require a further patch. > One of the concerns that never got resolved from what I've read in the > archives, was the use of a DWARF constant outside of DWARF code. > I am not sure I understand the problem, though. Was it the use of > constant zero when populating this field when reading stabs debug > info, or anything else? Yes, it was the use of an unnamed constant: http://sourceware.org/ml/gdb-patches/2009-04/msg00196.html > As far as I am concerned, I can't see a problem with using DWARF > declarations even from stabs. We could include the dwarf2.h header in the stabs reader and set the calling convention to DW_CC_normal in all cases. > Just a couple of formatting nits: > >> + if (struct_return >> + && reg_paras[para_regnum-1] != nargs) > > and > >> + while (type >> + && can_dereference (type)) > > You probably want to join the two lines in one. gdb_indent.sh, our > automatic indentation program would (though no one uses it, it makes > pretty bad choices sometimes). I think it'd make the code a little > easier to read too. Ok, will do. > diff --git a/include/elf/dwarf2.h b/include/elf/dwarf2.h >> index a7448dc..efa786e 100644 >> --- a/include/elf/dwarf2.h >> +++ b/include/elf/dwarf2.h >> @@ -662,7 +662,8 @@ enum dwarf_calling_convention >> DW_CC_normal = 0x1, >> DW_CC_program = 0x2, >> DW_CC_nocall = 0x3, >> - DW_CC_GNU_renesas_sh = 0x40 >> + DW_CC_GNU_renesas_sh = 0x40, >> + DW_CC_GNU_borland_fastcall_i386 = 0x41 > > This part is maintained by binutils, I believe. You'll need > to ask them for approval of this change. Tom said it came from gcc (http://sourceware.org/ml/gdb-patches/2009-04/msg00063.html ) and I did submit a patch there: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00301.html . I did not get any reaction to that patch (and I guess it's not been applied). Later on, Tom clarified that he thought that the gdb and gcc versions of dwarf2.h should actually be merged into a single copy, but that I shouldn't worry about this since the divergence started before my patch: http://sourceware.org/ml/gdb-patches/2009-04/msg00099.html Jonas