Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: "Trond Eivind Glomsrød" <teg@redhat.com>,
	gdb-patches@sources.redhat.com
Subject: Re: [PATCH] ia64-tdep.c: Only warn about slot numbers > 2
Date: Thu, 22 Mar 2001 08:35:00 -0000	[thread overview]
Message-ID: <1010322163518.ZM14929@ocotillo.lan> (raw)
In-Reply-To: <3ABA1EEE.3B6DC6E9@cygnus.com>

On Mar 22, 10:49am, Andrew Cagney wrote:

> Kevin Buettner wrote:
> 
> > +  /* Warn about slot numbers greater than 2.  We used to generate
> > +     an error here on the assumption that the user entered an invalid
> > +     address.  But, sometimes GDB itself requests an invalid address.
> > +     This can (easily) happen when execution stops in a function for
> > +     which there are no symbols.  The prologue scanner will attempt to
> > +     find the beginning of the function - if the nearest symbol
> > +     happens to not be aligned on a bundle boundary (16 bytes), the
> > +     resulting starting address will cause GDB to think that the slot
> > +     number is too large.
> > +
> > +     So we warn about it and set the slot number to zero.  It is
> > +     not necessarily a fatal condition, particularly if debugging
> > +     at the assembly language level.  */
> 
> Is this a warning or an internal warning?

I think it should be a warning.  The condition that it's warning about
can easily be generated by the user.  Also, even though GDB generates
it, I don't think there's much we can do to guard against it.  (If
there were, I would've fixed GDB elsewhere!)

> Hmm, that in turn begs the question:  Should there be the function
> internal_warning() to match internal_error()?

Probably.

What is the difference between warning() and internal_warning() aside
from the fact that the filename and line number are printed for the
latter?  I.e, is there some way the user can tell GDB to shut up
about internal warnings?

> One of those secret plans involves adding the code:
> 
> 	static int been_here_before = 0;
> 	if (! been_here_before && warning_deprecated)
> 	  {
> 	    been_here_before = 1;
> 	    internal_warning (__FILE__, __LINE__, __FUNCTION__,
> 			      "deprecated function called");
> 	  }
> 
> to all deprecated functions.

I think something like this would need to be shut off for ordinary
users.  But GDB developers should be forced to run GDB with this
turned on.  It might be just enough of a thorn to persuade us to
abandon deprecated functions in relatively short order.  (Which I
assume was the intent of this now-not-so-secret plan?)

Kevin


  parent reply	other threads:[~2001-03-22  8:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-21 18:34 Kevin Buettner
     [not found] ` <3ABA1EEE.3B6DC6E9@cygnus.com>
2001-03-22  8:35   ` Kevin Buettner [this message]
2001-03-22 18:09     ` 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=1010322163518.ZM14929@ocotillo.lan \
    --to=kevinb@cygnus.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=teg@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