From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11546 invoked by alias); 3 Jun 2005 23:59:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11539 invoked by uid 22791); 3 Jun 2005 23:59:20 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 03 Jun 2005 23:59:20 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 453744795A; Fri, 3 Jun 2005 16:59:18 -0700 (PDT) Date: Fri, 03 Jun 2005 23:59:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/hppa] Can not insert breakpoint at address higher than 0xFFFFFF Message-ID: <20050603235918.GD1266@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2005-06/txt/msg00038.txt.bz2 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2398 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 * 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 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hppa-tdep.c.diff" Content-length: 681 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 --l76fUT7nc3MelDdI--