Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: PAUL GILLIAM <pgilliam@us.ibm.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Fixes problem setting breakpoint in dynamic loader
Date: Thu, 06 Jul 2006 01:01:00 -0000	[thread overview]
Message-ID: <1152143843.6282.49.camel@dufur.beaverton.ibm.com> (raw)
In-Reply-To: <200606172021.k5HKL82O013629@elgar.sibelius.xs4all.nl>

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

On Sat, 2006-06-17 at 22:21 +0200, Mark Kettenis wrote:
> > From: PAUL GILLIAM <pgilliam@us.ibm.com>
> > Date: Wed, 24 May 2006 16:26:11 -0700
> > 
> > --=-z0a1QHXPsj5sKoA5562L
> > Content-Type: text/plain
> > Content-Transfer-Encoding: 7bit
> > 
> > On PowerPC-64, with 64-bit executables, GDB has been giving this message
> > for a while:
> > 
> >         warning: Unable to find dynamic linker breakpoint function.
> >         GDB will be unable to debug shared library initializers
> >         and track explicitly loaded dynamic code.
> > 
> > This is because "enable_break()" in solib-svr4.c was looking for the
> > symbol "._dl_debug_state" in the 64-bit dynamic loader and not finding
> > it.  This should not be a surprise because these 'dot' symbols have not
> > been used for a while.
> 
> Your patch removes "._dl_debug_state" from the list of symbols.
> Doesn't this break debugging old binaries that still have the 'dot'
> symbols?

No. The non-'dot' symbol "_dl_debug_state" will either be found in a
code segment or in a data segment.  If found in a code segment, we can
set the breakpoint at where ever the symbol points.  If it points to a
function descriptor that's OK because if it's in the code segment, a
function descriptor consists of executable code and a breakpoint can be
set there.  If found in the data segment, then it must be a function
descriptor and it just gets "dereferenced".

So I am attaching a new patch that addresses most of your comments in
http://sourceware.org/ml/gdb-patches/2006-06/msg00382.html
and deletes the "._dl_debug_state" entry in the table.

One thing not addressed is this:

> Also, I don't mind that the comment was rearranged, but I would like
> to see information regarding the two linker symbols retained in some
> fashion.

The two linker symbols issue is no longer relevant for this piece of
code: the "._dl_debug_state" symbol was just a crutch used to avoid
having to "dereference" the function descriptor pointed to by
"_dl_debug_state", should it happen to be in a data section.  Now there
is code to do just that.


OK to commit?
 


[-- Attachment #2: loader_break.diff --]
[-- Type: text/x-patch, Size: 3061 bytes --]

2006-07-04  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	6 Jul 2006 00:50:51 -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,38 @@
       /* 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 elsewhere. */
+	  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)
+	    /* 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);

[-- Attachment #3: rs6000.diff --]
[-- Type: text/x-patch, Size: 1287 bytes --]

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	23 Jun 2006 21:22:32 -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);
 }
 \f
 

  reply	other threads:[~2006-07-06  1:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-25  2:26 PAUL GILLIAM
2006-05-25 16:27 ` Daniel Jacobowitz
2006-05-25 22:58   ` PAUL GILLIAM
2006-05-25 23:12     ` Daniel Jacobowitz
2006-05-27 17:52       ` PAUL GILLIAM
2006-06-23 21:33         ` PAUL GILLIAM
2006-06-23 21:48           ` Mark Kettenis
2006-06-26 22:21             ` PAUL GILLIAM
2006-06-26 22:28             ` PAUL GILLIAM
2006-06-26 23:55               ` Kevin Buettner
2006-06-26 18:48           ` Kevin Buettner
2006-06-17 20:21 ` Mark Kettenis
2006-07-06  1:01   ` PAUL GILLIAM [this message]
2006-07-06  2:57     ` Daniel Jacobowitz
2006-07-06 16:10     ` Kevin Buettner
2006-07-16 18:57     ` Andreas Schwab
2006-07-19 21:55       ` PAUL GILLIAM
  -- strict thread matches above, loose matches on Subject: below --
2007-04-27 20:59 [PATCH] " Thiago Jung Bauermann
2007-06-14 23:38 ` Joseph S. Myers
2007-06-20 13:15   ` Daniel Jacobowitz
2007-06-20 14:21     ` Daniel Jacobowitz
2007-06-22 14:07       ` Thiago Jung Bauermann
2007-06-20 14:39     ` Ulrich Weigand
2007-06-25 21:28     ` Ulrich Weigand
2007-07-03 15:58       ` Daniel Jacobowitz
2007-06-26 18:43     ` Joel Brobecker
2006-05-20  6:21 [PATCH] -var-update Nick Roberts
2006-05-20 16:34 ` Daniel Jacobowitz
2006-05-21  2:04   ` Nick Roberts
2006-05-21  5:22     ` Daniel Jacobowitz
2006-05-21 23:04       ` Nick Roberts
2006-05-25  0:21         ` Nick Roberts
2006-05-25  0:26           ` [patch] Fixes problem setting breakpoint in dynamic loader PAUL GILLIAM
2006-05-25  0:29             ` PAUL GILLIAM

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=1152143843.6282.49.camel@dufur.beaverton.ibm.com \
    --to=pgilliam@us.ibm.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    /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