[RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF

[Joel Brobecker <brobecker@adacore.com>]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Hello,

A customer of ours reported that they were unable to break on certain
symbols unless the program be started. Here is the GDB output we get:

  (gdb)  break __gnat_raise_nodefer_with_msg
  Cannot break on '__gnat_raise_nodefer_with_msg' without a running program.

This is where the problem is:

| int
| hppa_pc_requires_run_before_use (CORE_ADDR pc)
| {
|   /* Sometimes we may pluck out a minimal symbol that has a negative address. 
|   
|      An example of this occurs when an a.out is linked against a foo.sl.
|      The foo.sl defines a global bar(), and the a.out declares a signature
|      for bar().  However, the a.out doesn't directly call bar(), but passes   
|      its address in another call.
|   
|      If you have this scenario and attempt to "break bar" before running,
|      gdb will find a minimal symbol for bar() in the a.out.  But that
|      symbol's address will be negative.  What this appears to denote is
|      an index backwards from the base of the procedure linkage table (PLT)
|      into the data linkage table (DLT), the end of which is contiguous
|      with the start of the PLT.  This is clearly not a valid address for
|      us to set a breakpoint on.
|   
|      Note that one must be careful in how one checks for a negative address.  
|      0xc0000000 is a legitimate address of something in a shared text
|      segment, for example.  Since I don't know what the possible range
|      is of these "really, truly negative" addresses that come from the
|      minimal symbols, I'm resorting to the gross hack of checking the
|      top byte of the address for all 1's.  Sigh.  */
| 
|   return (!target_has_stack && (pc & 0xFF000000));
| }

The problem is that the program built by our customer is large enough
that the address of certain symbol exceeds 0xFFFFFF, and hence triggers
the condition above.

But the condition above doesn't correspond to the comment. We think it
is an error, although it's always hard to tell with a hack. Anyway,
if changed the check to make sure that *all* bits in the top byte are
1's before forcing the user to start the program for this breakpoint.
This fixes the problem.

2005-06-03  Joel Brobecker  <brobecker@adacore.com>

        * hppa-tdep.c (hppa_pc_requires_run_before_use): Really test all
        bits in of type byte in address.

Tested on hppa-hpux, no regression.
OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: hppa-tdep.c.diff --]
[-- Type: text/plain, Size: 681 bytes --]

Index: gdb/hppa-tdep.c
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.3/gdb/hppa-tdep.c,v
retrieving revision 1.15
diff -u -p -r1.15 hppa-tdep.c
--- gdb/hppa-tdep.c	19 Mar 2005 01:15:18 -0000	1.15
+++ gdb/hppa-tdep.c	3 Jun 2005 20:11:14 -0000
@@ -2401,7 +2401,7 @@ hppa_pc_requires_run_before_use (CORE_AD
      minimal symbols, I'm resorting to the gross hack of checking the
      top byte of the address for all 1's.  Sigh.  */
 
-  return (!target_has_stack && (pc & 0xFF000000));
+  return (!target_has_stack && (pc & 0xFF000000) == 0xFF000000);
 }
 
 /* Return the GDB type object for the "standard" data type of data