From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-44334-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 1767 invoked by alias); 25 May 2006 22:56:06 -0000
Received: (qmail 1757 invoked by uid 22791); 25 May 2006 22:56:05 -0000
X-Spam-Check-By: sourceware.org
Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 22:56:01 +0000
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) 	by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4PMtvPr013351 	for <gdb-patches@sources.redhat.com>; Thu, 25 May 2006 18:55:57 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) 	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4PMtvjP229386 	for <gdb-patches@sources.redhat.com>; Thu, 25 May 2006 16:55:57 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) 	by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4PMtqjp010834 	for <gdb-patches@sources.redhat.com>; Thu, 25 May 2006 16:55:53 -0600
Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) 	by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4PMtq13010799; 	Thu, 25 May 2006 16:55:52 -0600
Subject: Re: [patch] Fixes problem setting breakpoint in dynamic loader
From: PAUL GILLIAM <pgilliam@us.ibm.com>
Reply-To: pgilliam@us.ibm.com
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
In-Reply-To: <20060525022635.GA15026@nevyn.them.org>
References: <1148513171.315.104.camel@dufur.beaverton.ibm.com> 	 <20060525022635.GA15026@nevyn.them.org>
Content-Type: multipart/mixed; boundary="=-j9HshHCZXjpR1vlhBAD/"
Date: Thu, 25 May 2006 22:58:00 -0000
Message-Id: <1148593970.315.131.camel@dufur.beaverton.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5)
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-05/txt/msg00463.txt.bz2


--=-j9HshHCZXjpR1vlhBAD/
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-length: 2159

On Wed, 2006-05-24 at 22:26 -0400, Daniel Jacobowitz wrote:
> On Wed, May 24, 2006 at 04:26:11PM -0700, PAUL GILLIAM wrote:
> > +	      interp_sect = bfd_get_section_by_name (tmp_bfd, ".plt");
> 
> > +	      interp_sect = bfd_get_section_by_name (tmp_bfd, ".opd");
> 
> Magic names...

These aren't magic: they are common to all 64-bit ELF ABIs.  Well, ok:
maybe they're enchanted.

> 
> > +	  if (interp_sect != 0)
> > +	    {
> > +	      /* Try to convert the function descriptor we found above, into
> > +		 the address we need.  It will be relocated below by adding
> > +		 "load_addr" to it. */
> > +	      char *buf = alloca (sizeof (LONGEST));
> > +	      if (bfd_get_section_contents (tmp_bfd, interp_sect, buf,
> > +					    sym_addr - sect_offset,
> > +					    sizeof (LONGEST)))
> > +		sym_addr = extract_unsigned_integer (buf, sizeof (LONGEST));
> > +	      else
> > +		sym_addr = 0;
> > +	    }
> > +        }
> > +
> 
> ... and a magic load; you have no idea what the format of a function
> descriptor is, at this point.
> 
uffda!  I'm afraid I was just a little bit ppc64-centric.

> Can you make convert_from_func_ptr_addr do what you need?  It needs a
> target_ops; conveniently you've got one (tmp_bfd_target).  Some targets
> use a memory read function which honors the supplied target_ops, others
> don't.  rs6000's doesn't so you'd need to fix that.
> 

Yes! Thank you: "gdbarch_convert_from_func_ptr_addr()" does exactly what
I want.  And while it's true that "rs6000_convert_from_func_ptr_addr()"
does not use the target_ops, "ppc64_linux_convert_from_func_ptr_addr()"
does and that is the version that is invoked on the configuration
reporting the error I am trying to fix.

I went ahead and converted "rs6000_convert_from_func_ptr_addr()" to use
target_ops, but because I have no way to test the change, I thought it
best to make it a separate patch.

So is it OK to commit the solib-svr4.c patch?

Does anyone want to test the rs6000-tdep.c patch and commit it?

-=# Paul #=-

PS:  Uffda is the word a Swed would exclaim when examining the bottom of
their shoe after stepping in a fresh cow-pie or after a similarly
annoying event.

--=-j9HshHCZXjpR1vlhBAD/
Content-Disposition: attachment; filename=loader_break.diff
Content-Type: text/x-patch; name=loader_break.diff; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-length: 3280

2006-05-25  Paul Gilliam  <pgilliam@us.ibm.com

	* solib-svr4.c (enable_break): Resolve break address when the
	symbol is found in the data section.

Index: solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.58
diff -a -u -r1.58 solib-svr4.c
--- solib-svr4.c	18 May 2006 20:38:56 -0000	1.58
+++ solib-svr4.c	25 May 2006 22:12:55 -0000
@@ -85,16 +85,6 @@
   "rtld_db_dlactivity",
   "_rtld_debug_state",
 
-  /* On the 64-bit PowerPC, the linker symbol with the same name as
-     the C function points to a function descriptor, not to the entry
-     point.  The linker symbol whose name is the C function name
-     prefixed with a '.' points to the function's entry point.  So
-     when we look through this table, we ignore symbols that point
-     into the data section (thus skipping the descriptor's symbol),
-     and eventually try this one, giving us the real entry point
-     address.  */
-  "._dl_debug_state",
-
   NULL
 };
 
@@ -1043,20 +1033,45 @@
       /* Now try to set a breakpoint in the dynamic linker.  */
       for (bkpt_namep = solib_break_names; *bkpt_namep != NULL; bkpt_namep++)
 	{
-          /* On ABI's that use function descriptors, there are usually
-             two linker symbols associated with each C function: one
-             pointing at the actual entry point of the machine code,
-             and one pointing at the function's descriptor.  The
-             latter symbol has the same name as the C function.
-
-             What we're looking for here is the machine code entry
-             point, so we are only interested in symbols in code
-             sections.  */
+	  /* What we're looking for here is the machine code entry point,
+	     so we are only interested in symbols in code sections.
+
+	     On ABI's that use function descriptors, the linker symbol with
+	     the same name as a C funtion points to that functions descriptor.
+	     when those function descriptors are in the code section, they
+	     contain executable code and we can set a breakpoint there. */
 	  sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
 	  if (sym_addr != 0)
 	    break;
 	}
 
+      if (sym_addr == 0)
+        {
+	  CORE_ADDR sect_offset;
+	  
+	  /* No symbol was found in a code section, so look in the data
+             sections.  This will only happen when the linker symbol points
+	     to a function descriptor that is in a data section. */
+	  for (bkpt_namep = solib_break_names; *bkpt_namep!=NULL; bkpt_namep++)
+	    {
+	      /* On ABI's that use function descriptors that are in the data
+	         section, */
+	      sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_DATA);
+	      if (sym_addr != 0)
+		break;
+	    }
+	  if (sym_addr == 0)
+	    {
+	      target_close (tmp_bfd_target, 0);
+	      goto bkpt_at_symbol;
+	    }
+
+	  /* Convert 'sym_addr' from a function pointer to an address. */
+	  sym_addr = gdbarch_convert_from_func_ptr_addr (current_gdbarch,
+							 sym_addr,
+							 tmp_bfd_target);
+        }
+
       /* We're done with both the temporary bfd and target.  Remember,
          closing the target closes the underlying bfd.  */
       target_close (tmp_bfd_target, 0);

--=-j9HshHCZXjpR1vlhBAD/
Content-Disposition: attachment; filename=rs6000.diff
Content-Type: text/x-patch; name=rs6000.diff; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-length: 1286

2006-05-25  Paul Gilliam  <pgilliam@us.ibm.com

        *rs6000-tdep.c (rs6000_convert_from_func_ptr_addr): Use target_ops.

Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.258
diff -a -u -r1.258 rs6000-tdep.c
--- rs6000-tdep.c	23 Apr 2006 14:15:01 -0000	1.258
+++ rs6000-tdep.c	25 May 2006 22:44:07 -0000
@@ -2338,7 +2338,8 @@
    inferior's memory space, with all its drawbacks.  To be able to
    call C++ virtual methods in the inferior (which are called via
    function pointers), find_function_addr uses this function to get the
-   function address from a function pointer.  */
+   function address from a function pointer.  It is also used by
+   enable_break from svr4_solib_create_inferior_hook.  */
 
 /* Return real function address if ADDR (a function pointer) is in the data
    space and is therefore a special function pointer.  */
@@ -2355,7 +2356,9 @@
     return addr;
 
   /* ADDR is in the data space, so it's a special function pointer. */
-  return read_memory_addr (addr, gdbarch_tdep (current_gdbarch)->wordsize);
+
+  return get_target_memory_unsigned (targ, addr,
+                                     gdbarch_tdep (current_gdbarch)->wordsize);
 }
 
 

--=-j9HshHCZXjpR1vlhBAD/--