* PR corefile/8210: Linux core files should use linux-thread-db.c
@ 2010-08-14 19:06 Pedro Alves
2010-08-18 12:28 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2010-08-14 19:06 UTC (permalink / raw)
To: gdb-patches
This enables using the linux-thread-db.c target on top of linux
core files. It mainly skips doing things that would go straight
to the linux-nat.c target, that only make sense when debugging
a live program. Lukily, after skipping those, we end up bypassing
all the linux-thread-db.c/linux-nat.c entanglement.
Before:
(gdb) info threads
During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x7f0f567be3a0.
6 LWP 6785 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
5 LWP 6781 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
4 LWP 6784 0x00007f0f567f2fe3 in select () from /lib/libc.so.6
3 LWP 6783 0x00007f0f567f2fe3 in select () from /lib/libc.so.6
2 LWP 6782 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
* 1 LWP 6780 0x00007f0f567be38d in nanosleep () from /lib/libc.so.6
After:
(gdb) info threads
During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) at 0x7f0f567be3a0.
6 Thread 0x7f0f5470f710 (LWP 6785) 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
5 Thread 0x7f0f56713710 (LWP 6781) 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
4 Thread 0x7f0f54f10710 (LWP 6784) 0x00007f0f567f2fe3 in select () from /lib/libc.so.6
3 Thread 0x7f0f55711710 (LWP 6783) 0x00007f0f567f2fe3 in select () from /lib/libc.so.6
2 Thread 0x7f0f55f12710 (LWP 6782) 0x00007f0f56d28464 in __lll_lock_wait () from /lib/libpthread.so.0
* 1 Thread 0x7f0f5712a700 (LWP 6780) 0x00007f0f567be38d in nanosleep () from /lib/libc.so.6
I also confirmed that one can now print TLS variables when debugging core files.
This will only work when these patches are applied:
<http://sourceware.org/ml/binutils/2010-08/msg00164.html>
<http://sourceware.org/ml/gdb-patches/2010-08/msg00207.html>
This is because libthread_db ignores threads that don't match the
overall process id that we return in the proc-service's
ps_getpid interface. Currently, on linux, we're using a fake
PID for core files, which obviously doesn't match what libthread_db
expects. The patches behind those links allow GDB to get
at the correct PID and stop using a fake one on x86 and x86-64,
and leaves the infrastructure in place for other archs.
--
Pedro Alves
2010-08-14 Pedro Alves <pedro@codesourcery.com>
PR corefile/8210
gdb/
* linux-thread-db.c (add_thread_db_info): Skip glibc/BZ5983
workaround on core files.
(try_thread_db_load_1): Don't try enabling thread event reporting
on core files.
(thread_db_load): Allow thread_db on core files.
(attach_thread): Don't check thread signals on core files, nor try
really attaching to the thread, nor enabling thread event event
reporting.
(thread_db_detach): Don't try disabing thread event reporting or
removing thread event breakpoints when debugging a core file.
(find_new_threads_callback): Don't try enabling thread event
reporting on core files.
(thread_db_find_new_threads_2): Don't look for a stopped lwp when
debugging a core file.
(thread_db_find_new_threads): Don't update thread
cores (processors) when debugging a core (dump).
---
gdb/linux-thread-db.c | 83 +++++++++++++++++++++++++++++++-------------------
1 file changed, 52 insertions(+), 31 deletions(-)
Index: src/gdb/linux-thread-db.c
===================================================================
--- src.orig/gdb/linux-thread-db.c 2010-08-14 18:40:08.000000000 +0100
+++ src/gdb/linux-thread-db.c 2010-08-14 18:40:03.000000000 +0100
@@ -189,7 +189,11 @@ add_thread_db_info (void *handle)
info = xcalloc (1, sizeof (*info));
info->pid = ptid_get_pid (inferior_ptid);
info->handle = handle;
- info->need_stale_parent_threads_check = 1;
+
+ /* The workaround works by reading from /proc/pid/status, so it is
+ disabled for core files. */
+ if (target_has_execution)
+ info->need_stale_parent_threads_check = 1;
info->next = thread_db_list;
thread_db_list = info;
@@ -737,7 +741,9 @@ try_thread_db_load_1 (struct thread_db_i
if (thread_db_list->next == NULL)
push_target (&thread_db_ops);
- enable_thread_event_reporting ();
+ /* Enable event reporting, but not when debugging a core file. */
+ if (target_has_execution)
+ enable_thread_event_reporting ();
/* There appears to be a bug in glibc-2.3.6: calls to td_thr_get_info fail
with TD_ERR for statically linked executables if td_thr_get_info is
@@ -869,13 +875,13 @@ thread_db_load (void)
if (info != NULL)
return 1;
- /* Don't attempt to use thread_db on targets which can not run
- (executables not running yet, core files) for now. */
- if (!target_has_execution)
+ /* Don't attempt to use thread_db on executables not running
+ yet. */
+ if (!target_has_registers)
return 0;
/* Don't attempt to use thread_db for remote targets. */
- if (!target_can_run (¤t_target))
+ if (!(target_can_run (¤t_target) || core_bfd))
return 0;
if (thread_db_load_search ())
@@ -1030,13 +1036,15 @@ attach_thread (ptid_t ptid, const td_thr
}
}
- check_thread_signals ();
+ if (target_has_execution)
+ check_thread_signals ();
if (ti_p->ti_state == TD_THR_UNKNOWN || ti_p->ti_state == TD_THR_ZOMBIE)
return 0; /* A zombie thread -- do not attach. */
/* Under GNU/Linux, we have to attach to each and every thread. */
- if (tp == NULL
+ if (target_has_execution
+ && tp == NULL
&& lin_lwp_attach_lwp (BUILD_LWP (ti_p->ti_lid, GET_PID (ptid))) < 0)
return 0;
@@ -1061,11 +1069,16 @@ attach_thread (ptid_t ptid, const td_thr
info = get_thread_db_info (GET_PID (ptid));
- /* Enable thread event reporting for this thread. */
- err = info->td_thr_event_enable_p (th_p, 1);
- if (err != TD_OK)
- error (_("Cannot enable thread event reporting for %s: %s"),
- target_pid_to_str (ptid), thread_db_err_str (err));
+ /* Enable thread event reporting for this thread, except when
+ debugging a core file. */
+ if (target_has_execution)
+ {
+ err = info->td_thr_event_enable_p (th_p, 1);
+ if (err != TD_OK)
+ error (_("Cannot enable thread event reporting for %s: %s"),
+ target_pid_to_str (ptid), thread_db_err_str (err));
+ }
+
return 1;
}
@@ -1097,14 +1110,17 @@ thread_db_detach (struct target_ops *ops
if (info)
{
- disable_thread_event_reporting (info);
+ if (target_has_execution)
+ {
+ disable_thread_event_reporting (info);
- /* Delete the old thread event breakpoints. Note that unlike
- when mourning, we can remove them here because there's still
- a live inferior to poke at. In any case, GDB will not try to
- insert anything in the inferior when removing a
- breakpoint. */
- remove_thread_event_breakpoints ();
+ /* Delete the old thread event breakpoints. Note that
+ unlike when mourning, we can remove them here because
+ there's still a live inferior to poke at. In any case,
+ GDB will not try to insert anything in the inferior when
+ removing a breakpoint. */
+ remove_thread_event_breakpoints ();
+ }
delete_thread_db_info (GET_PID (inferior_ptid));
}
@@ -1317,7 +1333,7 @@ find_new_threads_callback (const td_thrh
if (ti.ti_state == TD_THR_UNKNOWN || ti.ti_state == TD_THR_ZOMBIE)
return 0; /* A zombie -- ignore. */
- if (ti.ti_tid == 0)
+ if (ti.ti_tid == 0 && target_has_execution)
{
/* A thread ID of zero means that this is the main thread, but
glibc has not yet initialized thread-local storage and the
@@ -1417,19 +1433,23 @@ static void
thread_db_find_new_threads_2 (ptid_t ptid, int until_no_new)
{
td_err_e err;
- struct lwp_info *lp;
struct thread_db_info *info;
int pid = ptid_get_pid (ptid);
int i, loop;
- /* In linux, we can only read memory through a stopped lwp. */
- ALL_LWPS (lp, ptid)
- if (lp->stopped && ptid_get_pid (lp->ptid) == pid)
- break;
+ if (target_has_execution)
+ {
+ struct lwp_info *lp;
- if (!lp)
- /* There is no stopped thread. Bail out. */
- return;
+ /* In linux, we can only read memory through a stopped lwp. */
+ ALL_LWPS (lp, ptid)
+ if (lp->stopped && ptid_get_pid (lp->ptid) == pid)
+ break;
+
+ if (!lp)
+ /* There is no stopped thread. Bail out. */
+ return;
+ }
info = get_thread_db_info (GET_PID (ptid));
@@ -1480,8 +1500,9 @@ thread_db_find_new_threads (struct targe
thread_db_find_new_threads_1 (inferior_ptid);
- iterate_over_lwps (minus_one_ptid /* iterate over all */,
- update_thread_core, NULL);
+ if (target_has_execution)
+ iterate_over_lwps (minus_one_ptid /* iterate over all */,
+ update_thread_core, NULL);
}
static char *
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-14 19:06 PR corefile/8210: Linux core files should use linux-thread-db.c Pedro Alves
@ 2010-08-18 12:28 ` Pedro Alves
2010-08-18 14:29 ` Thiago Jung Bauermann
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2010-08-18 12:28 UTC (permalink / raw)
To: gdb-patches
On Saturday 14 August 2010 20:05:49, Pedro Alves wrote:
> PR corefile/8210
>
> gdb/
> * linux-thread-db.c (add_thread_db_info): Skip glibc/BZ5983
> workaround on core files.
> (try_thread_db_load_1): Don't try enabling thread event reporting
> on core files.
> (thread_db_load): Allow thread_db on core files.
> (attach_thread): Don't check thread signals on core files, nor try
> really attaching to the thread, nor enabling thread event event
> reporting.
> (thread_db_detach): Don't try disabing thread event reporting or
> removing thread event breakpoints when debugging a core file.
> (find_new_threads_callback): Don't try enabling thread event
> reporting on core files.
> (thread_db_find_new_threads_2): Don't look for a stopped lwp when
> debugging a core file.
> (thread_db_find_new_threads): Don't update thread
> cores (processors) when debugging a core (dump).
I've applied this as well.
--
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-18 12:28 ` Pedro Alves
@ 2010-08-18 14:29 ` Thiago Jung Bauermann
2010-08-18 14:40 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Thiago Jung Bauermann @ 2010-08-18 14:29 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Wed, 2010-08-18 at 13:28 +0100, Pedro Alves wrote:
> On Saturday 14 August 2010 20:05:49, Pedro Alves wrote:
>
> > PR corefile/8210
> >
> > gdb/
> > * linux-thread-db.c (add_thread_db_info): Skip glibc/BZ5983
> > workaround on core files.
> > (try_thread_db_load_1): Don't try enabling thread event reporting
> > on core files.
> > (thread_db_load): Allow thread_db on core files.
> > (attach_thread): Don't check thread signals on core files, nor try
> > really attaching to the thread, nor enabling thread event event
> > reporting.
> > (thread_db_detach): Don't try disabing thread event reporting or
> > removing thread event breakpoints when debugging a core file.
> > (find_new_threads_callback): Don't try enabling thread event
> > reporting on core files.
> > (thread_db_find_new_threads_2): Don't look for a stopped lwp when
> > debugging a core file.
> > (thread_db_find_new_threads): Don't update thread
> > cores (processors) when debugging a core (dump).
>
> I've applied this as well.
This is patch is great. IMHO it deserves a NEWS entry. :-)
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-18 14:29 ` Thiago Jung Bauermann
@ 2010-08-18 14:40 ` Pedro Alves
2010-08-26 19:13 ` [RFA/NEWS] " Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2010-08-18 14:40 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: gdb-patches
On Wednesday 18 August 2010 15:29:28, Thiago Jung Bauermann wrote:
> This is patch is great. IMHO it deserves a NEWS entry. :-)
Eh eh, I knew that was comming. :-) I'll take care of that a
bit later.
--
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RFA/NEWS] Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-18 14:40 ` Pedro Alves
@ 2010-08-26 19:13 ` Pedro Alves
2010-08-26 19:34 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2010-08-26 19:13 UTC (permalink / raw)
To: gdb-patches, Eli Zaretskii; +Cc: Thiago Jung Bauermann
On Wednesday 18 August 2010 15:40:22, Pedro Alves wrote:
> On Wednesday 18 August 2010 15:29:28, Thiago Jung Bauermann wrote:
> > This is patch is great. IMHO it deserves a NEWS entry. :-)
>
> Eh eh, I knew that was comming. :-) I'll take care of that a
> bit later.
And here it is. Okay to apply?
--
Pedro Alves
2010-08-26 Pedro Alves <pedro@codesourcery.com>
* NEWS: Mention libthread_db debugging with core files.
---
gdb/NEWS | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS 2010-08-26 14:49:39.000000000 +0100
+++ src/gdb/NEWS 2010-08-26 20:12:52.000000000 +0100
@@ -37,6 +37,29 @@
expression. Such a watchpoint is never deleted due to it going out
of scope.
+* GDB now displays pthread_t ids and allows inspecting TLS variables
+ when debugging core dumps on GNU/Linux.
+
+ GDB now activates thread debugging using the libthread_db library
+ when debugging GNU/Linux core dumps, similarly to when debugging
+ live processes. As a result, when debugging a core dump file, GDB
+ now able to display pthread_t ids of threads. For example, "info
+ threads" shows the same output as when debugging the process when it
+ was live. In earlier releases, you'd see something like this:
+
+ (gdb) info threads
+ * 1 LWP 6780 0x00007f0f567be38d main () at main.c:10
+
+ While now you see this:
+
+ (gdb) info threads
+ * 1 Thread 0x7f0f5712a700 (LWP 6780) main () at main.c:10
+
+ When debugging a core dump generated on a machine not the one used
+ to run GDB, you may need to point GDB at the correct libthread_db
+ library with the "set libthread-db-search-path". See the user
+ manual for more details on this command.
+
*** Changes in GDB 7.2
* Shared library support for remote targets by default
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFA/NEWS] Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-26 19:13 ` [RFA/NEWS] " Pedro Alves
@ 2010-08-26 19:34 ` Eli Zaretskii
2010-08-26 19:47 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2010-08-26 19:34 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, bauerman
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 26 Aug 2010 20:13:27 +0100
> Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
>
> On Wednesday 18 August 2010 15:40:22, Pedro Alves wrote:
> > On Wednesday 18 August 2010 15:29:28, Thiago Jung Bauermann wrote:
> > > This is patch is great. IMHO it deserves a NEWS entry. :-)
> >
> > Eh eh, I knew that was comming. :-) I'll take care of that a
> > bit later.
>
> And here it is. Okay to apply?
>
> --
> Pedro Alves
>
> 2010-08-26 Pedro Alves <pedro@codesourcery.com>
>
> * NEWS: Mention libthread_db debugging with core files.
It's okay, with two comments:
> +* GDB now displays pthread_t ids and allows inspecting TLS variables
> + when debugging core dumps on GNU/Linux.
Suggest to make a shorter header:
* GDB now supports thread debugging of core dumps on GNU/Linux.
> + When debugging a core dump generated on a machine not the one used
> + to run GDB, you may need to point GDB at the correct libthread_db
When debugging a core dump generated on a machine other than the one
used to run GDB, you may need ...
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFA/NEWS] Re: PR corefile/8210: Linux core files should use linux-thread-db.c
2010-08-26 19:34 ` Eli Zaretskii
@ 2010-08-26 19:47 ` Pedro Alves
0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2010-08-26 19:47 UTC (permalink / raw)
To: gdb-patches, Eli Zaretskii; +Cc: bauerman
On Thursday 26 August 2010 20:36:12, Eli Zaretskii wrote:
> It's okay, with two comments:
>
> > +* GDB now displays pthread_t ids and allows inspecting TLS variables
> > + when debugging core dumps on GNU/Linux.
>
> Suggest to make a shorter header:
>
> * GDB now supports thread debugging of core dumps on GNU/Linux.
>
> > + When debugging a core dump generated on a machine not the one used
> > + to run GDB, you may need to point GDB at the correct libthread_db
>
> When debugging a core dump generated on a machine other than the one
> used to run GDB, you may need ...
Ah, thanks. I was going in circles trying to make that sentence not
sound weird, and failing.
I've applied the below.
--
Pedro Alves
2010-08-26 Pedro Alves <pedro@codesourcery.com>
* NEWS: Mention libthread_db debugging with core files.
---
gdb/NEWS | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS 2010-08-26 20:33:43.000000000 +0100
+++ src/gdb/NEWS 2010-08-26 20:42:46.000000000 +0100
@@ -37,6 +37,31 @@
expression. Such a watchpoint is never deleted due to it going out
of scope.
+* GDB now supports thread debugging of core dumps on GNU/Linux.
+
+ GDB now activates thread debugging using the libthread_db library
+ when debugging GNU/Linux core dumps, similarly to when debugging
+ live processes. As a result, when debugging a core dump file, GDB
+ is now able to display pthread_t ids of threads. For example, "info
+ threads" shows the same output as when debugging the process when it
+ was live. In earlier releases, you'd see something like this:
+
+ (gdb) info threads
+ * 1 LWP 6780 main () at main.c:10
+
+ While now you see this:
+
+ (gdb) info threads
+ * 1 Thread 0x7f0f5712a700 (LWP 6780) main () at main.c:10
+
+ It is also now possible to inspect TLS variables when debugging core
+ dumps.
+
+ When debugging a core dump generated on a machine other than the one
+ used to run GDB, you may need to point GDB at the correct
+ libthread_db library with the "set libthread-db-search-path"
+ command. See the user manual for more details on this command.
+
*** Changes in GDB 7.2
* Shared library support for remote targets by default
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-08-26 19:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-14 19:06 PR corefile/8210: Linux core files should use linux-thread-db.c Pedro Alves
2010-08-18 12:28 ` Pedro Alves
2010-08-18 14:29 ` Thiago Jung Bauermann
2010-08-18 14:40 ` Pedro Alves
2010-08-26 19:13 ` [RFA/NEWS] " Pedro Alves
2010-08-26 19:34 ` Eli Zaretskii
2010-08-26 19:47 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).