breaks at thread create and delete fail on PPC64/Linux

breaks at thread create and delete fail on PPC64/Linux

[PAUL GILLIAM]

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

Here is an example:

        > gdb example64
        (gdb) start
        Breakpoint 1 at 0x10000734: file example.c, line 10.
        Starting program: /home/pgilliam/example64
        [Thread debugging using libthread_db enabled]
        [New Thread 4398046665456 (LWP 9443)]
        Warning:
        Cannot insert breakpoint -2.
        Error accessing memory address 0x9ce0: Input/output error.
        Cannot insert breakpoint -3.
        Error accessing memory address 0x9cf0: Input/output error.
        
        (gdb)

Here is the problem:

1) In linux-thread-db.c: enable_thread_event(), The routine 
"td_ta_event_addr" in the library "thread_db" gets called and
returns a function descriptor for the address at which to set
the breakpoints for the "create" and "delete" thread events
in the "pthread" library.

2) These address point at PLT entries in the '.opd' section.

3) 'dereferencing' the function descriptor should give the
actual address at which to set a breakpoint, but gives instead
the offset within the "pthread" library where the breakpoint
should be placed.

The attached patch 'fixes' the problem by looking up the load address of the
"pthread" library and adding that to the address from the PLT.	This seems to
do the trick, but THIS HAS ONLY BEEN TESTED WITH A 64-BIT GDB AND A 64-BIT
TARGET.  And it's a real HACK!!! 

But it does illustrate the problem.

So, should I try to change GDB so that enable_thread_event() gets called after
the dynamic loader has has a chance to relocate the .opd?

or

Find a better place way to do the relocation for just these two things?

-=# Paul Gilliam #=-















--- /home/pgilliam/linux-thread-db.c	2006-08-17 02:27:05.000000000 -0700
+++ hacked.linux-thread-db.c	2006-08-17 02:29:16.000000000 -0700
@@ -497,6 +497,7 @@
 static td_err_e
 enable_thread_event (td_thragent_t *thread_agent, int event, CORE_ADDR *bp)
 {
+  static CORE_ADDR thread_lib_reloc = 0;
   td_notify_t notify;
   td_err_e err;
 
@@ -514,7 +515,24 @@
 	     ? (CORE_ADDR) (intptr_t) notify.u.bptaddr
 	     : (CORE_ADDR) (uintptr_t) notify.u.bptaddr),
 	    &current_target));
-  create_thread_event_breakpoint ((*bp));
+  if (! thread_lib_reloc) {
+    char tbuf[1024];
+    FILE *pmf;
+
+    sprintf (tbuf, "/proc/%d/maps", proc_handle.pid);
+    pmf = fopen (tbuf, "r");
+    if (pmf) {
+      while (fgets( tbuf, sizeof(tbuf), pmf)) {
+	char *cp = rindex (tbuf, '/');
+	if (cp && strncmp (cp+1, "libpthread", 10) == 0) {
+	  thread_lib_reloc = (CORE_ADDR) strtol (tbuf, 0, 16);
+          break;
+	}
+      }
+      fclose (pmf);
+    }
+  }
+  create_thread_event_breakpoint ((*bp) + thread_lib_reloc);
 
   return TD_OK;
 }

[-- Attachment #2: hack.patch --]
[-- Type: text/x-patch, Size: 1039 bytes --]

--- /home/pgilliam/linux-thread-db.c	2006-08-17 02:27:05.000000000 -0700
+++ hacked.linux-thread-db.c	2006-08-17 02:29:16.000000000 -0700
@@ -497,6 +497,7 @@
 static td_err_e
 enable_thread_event (td_thragent_t *thread_agent, int event, CORE_ADDR *bp)
 {
+  static CORE_ADDR thread_lib_reloc = 0;
   td_notify_t notify;
   td_err_e err;
 
@@ -514,7 +515,24 @@
 	     ? (CORE_ADDR) (intptr_t) notify.u.bptaddr
 	     : (CORE_ADDR) (uintptr_t) notify.u.bptaddr),
 	    &current_target));
-  create_thread_event_breakpoint ((*bp));
+  if (! thread_lib_reloc) {
+    char tbuf[1024];
+    FILE *pmf;
+
+    sprintf (tbuf, "/proc/%d/maps", proc_handle.pid);
+    pmf = fopen (tbuf, "r");
+    if (pmf) {
+      while (fgets( tbuf, sizeof(tbuf), pmf)) {
+	char *cp = rindex (tbuf, '/');
+	if (cp && strncmp (cp+1, "libpthread", 10) == 0) {
+	  thread_lib_reloc = (CORE_ADDR) strtol (tbuf, 0, 16);
+          break;
+	}
+      }
+      fclose (pmf);
+    }
+  }
+  create_thread_event_breakpoint ((*bp) + thread_lib_reloc);
 
   return TD_OK;
 }

Re: breaks at thread create and delete fail on PPC64/Linux

[Daniel Jacobowitz]

On Mon, Aug 28, 2006 at 04:15:03PM -0700, PAUL GILLIAM wrote:
> 3) 'dereferencing' the function descriptor should give the
> actual address at which to set a breakpoint, but gives instead
> the offset within the "pthread" library where the breakpoint
> should be placed.
> 
> The attached patch 'fixes' the problem by looking up the load address of the
> "pthread" library and adding that to the address from the PLT.	This seems to
> do the trick, but THIS HAS ONLY BEEN TESTED WITH A 64-BIT GDB AND A 64-BIT
> TARGET.  And it's a real HACK!!! 
> 
> But it does illustrate the problem.
> 
> So, should I try to change GDB so that enable_thread_event() gets called after
> the dynamic loader has has a chance to relocate the .opd?

Here's my question: why isn't that happening already?  Don't we get
shared library events after relocation processing?  Or do we get one
before and one after?

-- 
Daniel Jacobowitz
CodeSourcery

Re: breaks at thread create and delete fail on PPC64/Linux

[PAUL GILLIAM]

On Mon, 2006-08-28 at 19:22 -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 28, 2006 at 04:15:03PM -0700, PAUL GILLIAM wrote:
> > 3) 'dereferencing' the function descriptor should give the
> > actual address at which to set a breakpoint, but gives instead
> > the offset within the "pthread" library where the breakpoint
> > should be placed.
> > 
> > The attached patch 'fixes' the problem by looking up the load address of the
> > "pthread" library and adding that to the address from the PLT.	This seems to
> > do the trick, but THIS HAS ONLY BEEN TESTED WITH A 64-BIT GDB AND A 64-BIT
> > TARGET.  And it's a real HACK!!! 
> > 
> > But it does illustrate the problem.
> > 
> > So, should I try to change GDB so that enable_thread_event() gets called after
> > the dynamic loader has has a chance to relocate the .opd?
> 
> Here's my question: why isn't that happening already?  Don't we get
> shared library events after relocation processing?  Or do we get one
> before and one after?

I don't think this is a "normal" shared library event at all: it's a
thread thing.

I need to do some more research to say for sure.

-=# Paul #=-

Re: breaks at thread create and delete fail on PPC64/Linux

[Mark Kettenis]

> Date: Mon, 28 Aug 2006 19:22:06 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Mon, Aug 28, 2006 at 04:15:03PM -0700, PAUL GILLIAM wrote:
> > 3) 'dereferencing' the function descriptor should give the
> > actual address at which to set a breakpoint, but gives instead
> > the offset within the "pthread" library where the breakpoint
> > should be placed.
> > 
> > The attached patch 'fixes' the problem by looking up the load
> > address of the "pthread" library and adding that to the address
> > from the PLT. This seems to do the trick, but THIS HAS ONLY BEEN
> > TESTED WITH A 64-BIT GDB AND A 64-BIT TARGET.  And it's a real
> > HACK!!!
> > 
> > But it does illustrate the problem.
> > 
> > So, should I try to change GDB so that enable_thread_event() gets
> > called after the dynamic loader has has a chance to relocate the
> > .opd?
> 
> Here's my question: why isn't that happening already?  Don't we get
> shared library events after relocation processing?  Or do we get one
> before and one after?

Normally we get an event right before a shared library and its
dependencies is loaded and right after.  At that last event things are
supposed to be in a consistent state, so relocations should have been
processed (except for relocations to be resilved by lazy binding of
course).

Mark

Re: breaks at thread create and delete fail on PPC64/Linux

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 09:03:31PM +0200, Mark Kettenis wrote:
> > Here's my question: why isn't that happening already?  Don't we get
> > shared library events after relocation processing?  Or do we get one
> > before and one after?
> 
> Normally we get an event right before a shared library and its
> dependencies is loaded and right after.  At that last event things are
> supposed to be in a consistent state, so relocations should have been
> processed (except for relocations to be resilved by lazy binding of
> course).

Is one of these before constructors and the other after, do you know?
How about relocation processing?  We really want to insert these
breakpoints before constructors; it's not unheard of to create a thread
in a shared library constructor.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breaks at thread create and delete fail on PPC64/Linux

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 09:03:31PM +0200, Mark Kettenis wrote:
> Normally we get an event right before a shared library and its
> dependencies is loaded and right after.  At that last event things are
> supposed to be in a consistent state, so relocations should have been
> processed (except for relocations to be resilved by lazy binding of
> course).

I happened to stumble across this bug report from John Reiser today,
which seems to explain Paul's trouble:
  http://sourceware.org/bugzilla/show_bug.cgi?id=2328

He's even got a patch for it, but it isn't in the bug report.  John,
any change that you could break it out of the other patches and submit
it?

In the mean time, it's over here:
  http://www.bitwagon.com/glibc-audit/glibc-audit.html

-- 
Daniel Jacobowitz
CodeSourcery

Re: breaks at thread create and delete fail on PPC64/Linux

[John Reiser]

Daniel Jacobowitz wrote:
> On Tue, Aug 29, 2006 at 09:03:31PM +0200, Mark Kettenis wrote:
> 
>>Normally we get an event right before a shared library and its
>>dependencies is loaded and right after.  At that last event things are
>>supposed to be in a consistent state, so relocations should have been
>>processed (except for relocations to be resilved by lazy binding of
>>course).
> 
> 
> I happened to stumble across this bug report from John Reiser today,
> which seems to explain Paul's trouble:
>   http://sourceware.org/bugzilla/show_bug.cgi?id=2328
> 
> He's even got a patch for it, but it isn't in the bug report.  John,
> any change that you could break it out of the other patches and submit
> it?
> 
> In the mean time, it's over here:
>   http://www.bitwagon.com/glibc-audit/glibc-audit.html
> 

Attached in Comment #1 of
   http://sourceware.org/bugzilla/show_bug.cgi?id=2328

-- 
John Reiser, jreiser@BitWagon.com