From: Jonas Maebe <jonas.maebe@elis.ugent.be>
To: Joel Brobecker <brobecker@adacore.com>
Cc: tromey@redhat.com, Mark Kettenis <mark.kettenis@xs4all.nl>,
gdb-patches@sourceware.org
Subject: Re: [patch] Set calling convention of methods
Date: Wed, 30 Sep 2009 11:18:00 -0000 [thread overview]
Message-ID: <8F3B6095-4766-432D-ABB5-AB4DAA2D5572@elis.ugent.be> (raw)
In-Reply-To: <20090930000225.GA10338@adacore.com>
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
next prev parent reply other threads:[~2009-09-30 11:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 19:51 Jonas Maebe
2009-04-10 17:34 ` Tom Tromey
2009-04-20 8:40 ` Jonas Maebe
2009-04-20 18:27 ` Tom Tromey
2009-04-22 17:45 ` Jonas Maebe
2009-04-22 19:22 ` Tom Tromey
2009-04-22 22:16 ` Mark Kettenis
2009-06-04 8:23 ` Jonas Maebe
2009-06-04 18:19 ` Tom Tromey
2009-06-10 20:44 ` Jonas Maebe
2009-06-18 21:45 ` Fwd: " Jonas Maebe
2009-09-30 0:02 ` Joel Brobecker
2009-09-30 11:18 ` Jonas Maebe [this message]
2009-09-30 14:54 ` Jonas Maebe
2009-09-30 15:22 ` Mark Kettenis
2009-09-30 16:25 ` Joel Brobecker
2009-10-01 9:18 ` Jonas Maebe
2009-10-01 22:04 ` Joel Brobecker
2009-10-02 9:21 ` Mark Kettenis
2009-09-30 16:10 ` Joel Brobecker
2009-09-30 17:36 ` Joel Brobecker
2009-09-30 16:47 ` Tom Tromey
2009-09-30 17:32 ` Joel Brobecker
2009-09-30 17:35 ` Tom Tromey
2009-10-01 9:21 ` Jonas Maebe
2009-11-03 9:43 ` Jonas Maebe
2009-11-03 14:19 ` Joel Brobecker
2009-07-06 20:50 ` Jonas Maebe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8F3B6095-4766-432D-ABB5-AB4DAA2D5572@elis.ugent.be \
--to=jonas.maebe@elis.ugent.be \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox