Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com, Jason Merrill <jason@redhat.com>
Subject: Re: RFA: MI tests: tolerate prototypes
Date: Wed, 06 Feb 2002 10:48:00 -0000	[thread overview]
Message-ID: <npvgdamolw.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <20020206004829.A1357@nevyn.them.org>


Daniel Jacobowitz <drow@mvista.com> writes:
> > Ah, by building `prototype'-style types for all the functions, even
> > those declared without prototypes, and using the called-as types as
> > the prototype argument types.  It'll work because, even though the
> > type claims to be prototyped, the argument types are such that we end
> > up doing the same promotions required by the rules for calling
> > non-prototyped functions.
> 
> So, the question becomes - do we need MAYBE_PROTOTYPED?  If we accept
> that the types marked in stabs as parameters are promoted types, then
> we can simply mark stabs functions as being prototyped, and trust
> TYPE_FLAG_PROTOTYPED more than we do.

If we do that, then:
- Dwarf 2 will continue to work correctly, since its prototype info
  has always been accurate,
- under STABS, calls to functions whose definitions we have debug info
  for will always work, unlike the current state of affairs, and 
- under STABS, calls via function pointers will do non-prototyped
  argument promotion, which is no worse than now.

Sounds good to me.

It does bother me, sort of on principle, that we won't really have
info about which functions were declared in which way.  I mean,
prototypedness is a real property of function types in ISO C.  But
given that our debug format doesn't carry the info we need, I guess
I'll just get over it. :)




  reply	other threads:[~2002-02-06 18:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-03 13:04 Jim Blandy
2002-02-03 15:01 ` Daniel Jacobowitz
2002-02-05 15:54   ` Jim Blandy
2002-02-05 17:21     ` Daniel Jacobowitz
2002-02-05 20:30       ` Jim Blandy
2002-02-05 21:48         ` Daniel Jacobowitz
2002-02-06 10:48           ` Jim Blandy [this message]
2002-02-06 16:14             ` Andrew Cagney
2002-02-06 16:24               ` Daniel Jacobowitz
2002-02-07 11:01               ` Jim Blandy
2002-02-07 12:27                 ` Daniel Jacobowitz
2002-02-08 10:03                   ` Jim Blandy
2002-02-08  5:16       ` function pointer stabs (was Re: RFA: MI tests: tolerate prototypes) Jason Merrill
2002-02-08  7:44         ` Daniel Jacobowitz
2002-02-08 11:37           ` Jim Blandy
2002-02-08 14:51           ` Jim Blandy
2002-02-09 12:15             ` Jim Blandy
2002-02-09 14:13               ` Daniel Jacobowitz
2002-02-03 16:29 ` RFA: MI tests: tolerate prototypes Andrew Cagney

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=npvgdamolw.fsf@zwingli.cygnus.com \
    --to=jimb@zwingli.cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jason@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