[PATCH] ia64-tdep.c: Only warn about slot numbers > 2

[PATCH] ia64-tdep.c: Only warn about slot numbers > 2

[Kevin Buettner]

I've just committed the changes below.

This patch addresses the concerns raised in the following bug report:

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=32544

In particular, GDB doesn't segfault anymore.  A warning message
regarding slot numbers that are greater than zero is still printed,
but IMO, it is better to print these to alert the user that something
may wrong...

	* ia64-tdep.c (fetch_instruction): Warn about slot numbers greater
	than two instead of generating an error.

Index: ia64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ia64-tdep.c,v
retrieving revision 1.15
diff -u -p -r1.15 ia64-tdep.c
--- ia64-tdep.c	2001/03/01 01:39:21	1.15
+++ ia64-tdep.c	2001/03/22 01:55:48
@@ -492,8 +492,25 @@ fetch_instruction (CORE_ADDR addr, instr
   long long template;
   int val;
 
+  /* 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.  */
   if (slotnum > 2)
-    error("Can't fetch instructions for slot numbers greater than 2.");
+    {
+      warning ("Can't fetch instructions for slot numbers greater than 2.\n"
+	       "Using slot 0 instead");
+      slotnum = 0;
+    }
 
   addr &= ~0x0f;
 

Re: [PATCH] ia64-tdep.c: Only warn about slot numbers > 2

[Kevin Buettner]

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

Re: [PATCH] ia64-tdep.c: Only warn about slot numbers > 2

[Andrew Cagney]

Kevin Buettner wrote:

> 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?

An internal error is where GDB has discovered that it is about to shot
its self.
An internal warning is where GDB finds out that the shot missed, well
almost, it hit its foot.

Normal errors() and warnings() are for situtations that are external to
GDB - bad object file, messed up address from the target, invalid user
command, ....

> 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?)

Just FYI,

We're already doing this for commands.  GDB reports back:

  (gdb) show architecture
  The target architecture is assumed to be i386
  (gdb) info architecture
  Warning: command 'info architecture' is deprecated.
  Use 'set architecture'.

  Available architectures are:
  Segmentation fault (core dumped)

(er, oops, drats PRMS relies on cookies :-( :-)

I'm not sure what the mechanism should be however GDB does need to start
alerting users (not GDB developers) that the target they are using
depends on deprecated features and, consequently, the target likely be
obsoleted in the next release of GDB.

	Andrew