List Info

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




breaks at thread create and delete fail on PPC64/Linux
user name
2006-08-28 23:15:03
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;
 }
breaks at thread create and delete fail on PPC64/Linux
user name
2006-08-28 23:22:06
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
breaks at thread create and delete fail on PPC64/Linux
user name
2006-08-28 23:26:39
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 #=-

breaks at thread create and delete fail on PPC64/Linux
user name
2006-08-29 19:03:31
> Date: Mon, 28 Aug 2006 19:22:06 -0400
> From: Daniel Jacobowitz <drowfalse.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
breaks at thread create and delete fail on PPC64/Linux
user name
2006-08-29 19:08:18
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
[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )