GDB m68k debug multi-thread application fails: capability not available
Hello, On a ColdFire (twr-mcf5441x) board, I am trying to debug an application linked with -lpthread, but GDB fails: Starting program: /upcodepr.linux.mcf54415 Reading symbols from /lib/ld.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] Reading symbols from /lib/librt.so.1...done. [New Thread 0x60180210 (LWP 621)] [New Thread 0x609814c0 (LWP 624)] Cannot find user-level thread for LWP 621: capability not available I am using the Freescale ltib package to build the kernel (2.6.29). GCC is gcc-4.4.54-eglibc-2.10.54 GDB version is 6.6.50.20070821-cvs The application was linked against the glibc included in the tool chain, and the same glibc is included on the target. The library files exist and have the same dates so I assume they are in sync. Also, they are not stripped. Single threaded apps. can be loaded and debugged ok. Any help on how to make GDB find user level threads is appreciated! Regards, - Lars Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.___ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: GDB m68k debug multi-thread application fails: capability not available
Lars - I realize this is a very old post but I am wondering if you ever figured this out. I am running into the same problem and have found very, very little on the web that is useful. Any insight you can add would be most appreciated. Regards, John On Friday, January 14, 2011 7:37:12 AM UTC-5, Horvath, Lars Michael wrote: > Hello, > > > On > a ColdFire (twr-mcf5441x) board, I am trying to debug an application linked > with -lpthread, but GDB fails: > > > Starting > program: /upcodepr.linux.mcf54415 > > Reading symbols > from /lib/ld.so.1...done. > > Reading symbols > from /lib/libc.so.6...done. > > Reading symbols > from /lib/libpthread.so.0...done. > > [Thread debugging using libthread_db enabled] > > Reading symbols > from /lib/librt.so.1...done. > > [New Thread 0x60180210 (LWP 621)] > > [New Thread 0x609814c0 (LWP 624)] > > Cannot find > user-level thread for LWP 621: capability not available > > > I > am using the Freescale ltib package to build the kernel (2.6.29). > > > GCC > is gcc-4.4.54-eglibc-2.10.54 > > > GDB > version is 6.6.50.20070821-cvs > > > The > application was linked against the glibc included in the tool chain, and the > same glibc is included on the target. The library files exist and have the > same > dates so I assume they are in sync. Also, they are not stripped. > > > Single > threaded apps. can be loaded and debugged ok. > > > Any > help on how to make GDB find user level threads is appreciated! > > > Regards, > > > - > Lars > > > > > > > > > > > > > > Please be advised that this email may contain confidential > > information. If you are not the intended recipient, please notify us > > by email by replying to the sender and delete this message. The > > sender disclaims that the content of this email constitutes an offer > > to enter into, or the acceptance of, any agreement; provided that the > > foregoing does not invalidate the binding effect of any digital or > > other electronic reproduction of a manual signature that is included > > in any attachment. ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: GDB m68k debug multi-thread application fails: capability not available
Den onsdag den 29. maj 2013 01.16.51 UTC+2 skrev john@gmail.com:
> Lars - I realize this is a very old post but I am wondering if you ever
> figured this out. I am running into the same problem and have found very,
> very little on the web that is useful. Any insight you can add would be most
> appreciated.
>
Hi John,
Here is a patch for gdb 6.6 that fixed the problem for me. There are two
patches, and below is the spec file I used (with Freescale ltib and kernel
2.6.29).
Regards,
Lars
---
%define pfx /opt/freescale/rootfs/%{_target_cpu}
%define cs_version 4.2-82
Summary : Gdb - GNU Source level debugger for C, C++
Name: gdb
Version : 6.6
Release : 2
License : GPL
Vendor : Freescale
Packager: Stuart Hughes/Steve Papacharalambous
Group : Development/Debuggers
Source : %{name}-%{version}.tar.gz
Patch0 : gdb-6.0-tcsetpgrp.patch
Patch1 : %{name}-%{cs_version}-from-fsf-6_6.diff.gz
Patch2 : %{name}-%{version}-UPAGES-undefined.patch
BuildRoot : %{_tmppath}/%{name}
Prefix : %{pfx}
%Description
%{summary}
Notes:
This gdb package is built using gdb-6.6 plus the gdb patch from the
CodeSourcery %{cs_version} release: gdb-%{cs_version}-from-fsf-6_6.diff
The gdb tarball can be obtained from any of the GNU ftp sites or their mirrors.
The CodeSourcery patch can be obtained by downloading the source rpm:
freescale-powerpc-linux-gnu-%{cs_version}.src.rpm from:
http://www.codesourcery.com/gnu_toolchains/power/download.html and then
extracting the gdb patch from this source rpm.
requires: libtermcap and ncurses
%Prep
%setup
%patch0 -p1
%patch1 -p1
%patch2 -p1
# Temporary hack. Stevep
# This is to prevent the following error occuring on some build systems:
# [snip]
# Doing pdf in readline
# make[3]: Entering directory
`/home/stevep/work/ltib/rpm/BUILD/gdb-6.6/readline'
# ( cd doc && make -w pdf )
# make[4]: Entering directory
`/home/stevep/work/ltib/rpm/BUILD/gdb-6.6/readline/doc'
# TEXINPUTS=.:../.././readline/doc:$TEXINPUTS ../.././readline/doc/texi2dvi
../.././readline/doc/rlman.texi
# This is TeX, Version 3.14159 (Web2C 7.3.1)
# (/home/stevep/work/ltib/rpm/BUILD/gdb-6.6/readline/doc/rlman.texi
# (/usr/share/texmf/tex/texinfo/texinfo.tex
# Loading texinfo [version 1999-09-25.10]: Basics, pdf, fonts, page headings,
# tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
# cross references, (/usr/share/texmf/tex/plain/dvips/epsf.tex) localization,
# and turning on texinfo input format.) (rlman.aux) (version.texi)
# ! Undefined control sequence.
# l.11 @copying
#
# ?
# [/snip]
perl -pi.orig -e 's,^\@copying,\@comment \@copying,;
s,^\@end\s+copying,\@comment \@end copying,;
s,^\@insertcopying,\@comment \@insertcopying,;'
readline/doc/rlman.texi
perl -pi.orig -e 's,^\@copying,\@comment \@copying,;
s,^\@end\s+copying,\@comment \@end copying,;
s,^\@insertcopying,\@comment \@insertcopying,;'
readline/doc/history.texi
perl -pi.orig -e 's,^\@copying,\@comment \@copying,;
s,^\@end\s+copying,\@comment \@end copying,;
s,^\@insertcopying,\@comment \@insertcopying,;'
readline/doc/rluserman.texi
%Build
ORIG_PATH=$PATH
# This is the optimised host type. Needed to prevent infering a native build
OPT_CFGHOST=`echo ${TOOLCHAIN_PREFIX} | perl -n -e 's,-$,,;print'`
# Ensure that build is never the same as hostA.
GDB_BUILD=`echo %{_build} | sed s/-/-build_/`
# Set up the host rpm command. This is done so that the version of expat
# on the host system can be determined. This is needed for cross-gdb with
# xml support enabled.
if [ -x /bin/rpm ]
then
HOST_RPM="/bin/rpm"
elif [ -x /usr/bin/rpm ]
then
HOST_RPM="/usr/bin/rpm"
else
HOST_RPM=""
fi
# Get the version of the host expat package and determine whether it is
# too old to provide cross-gdb xml support.
# Sigh, this is very ugly!
if [ -n ${HOST_RPM} ]
then
HOST_EXPAT_VER=`${HOST_RPM} -q expat | perl -p -e 's,expat-(.*)-\d+$,$1,'`
HOST_EXPAT_VER1=`echo ${HOST_EXPAT_VER} | cut -d. -f1`
HOST_EXPAT_VER2=`echo ${HOST_EXPAT_VER} | cut -d. -f2`
HOST_EXPAT_VER3=`echo ${HOST_EXPAT_VER} | cut -d. -f3`
# Starting with the first compare each of the host expat version numbers
# with the mimimum required. Not pretty!!
if [ ${HOST_EXPAT_VER1} -gt 1 ]
then
HOST_EXPAT_TOO_OLD="no"
elif [ ${HOST_EXPAT_VER1} -eq 1 ]
then
if [ ${HOST_EXPAT_VER2} -gt 95 ]
then
HOST_EXPAT_TOO_OLD="no"
elif [ ${HOST_EXPAT_VER2} -eq 95 ]
then
if [ ${HOST_EXPAT_VER3} -ge 5 ]
then
HOST_EXPAT_TOO_OLD="no"
else
HOST_EXPAT_TOO_OLD="yes"
fi
else
HOST_EXPAT_TOO_OLD="yes"
fi
else
HOST_EXPAT_TOO_OLD="yes"
fi
els
Re: GDB m68k debug multi-thread application fails: capability not available [PATCH 2/2] gdb-6.6-UPAGES-undefined.patch
diff -rupaN gdb-6.6-orig/bfd/hosts/m68klinux.h gdb-6.6/bfd/hosts/m68klinux.h --- gdb-6.6-orig/bfd/hosts/m68klinux.h 2010-08-09 13:28:14.0 +0800 +++ gdb-6.6/bfd/hosts/m68klinux.h 2010-08-09 13:30:28.0 +0800 @@ -20,6 +20,12 @@ /* Linux dumps "struct task_struct" at the end of the core-file. This structure is currently 2512 bytes long, but we allow up to 4096 bytes to allow for some future growth. */ + +#define NBPG 4096 +#define UPAGES 1 +#define HOST_TEXT_START_ADDR (u.start_code) +#define HOST_STACK_END_ADDR (u.start_stack + u.u_ssize * NBPG) + #define TRAD_CORE_EXTRA_SIZE_ALLOWED 4096 #define TRAD_UNIX_CORE_FILE_FAILING_SIGNAL(abfd) \ ((abfd)->tdata.trad_core_data->u.signal) ___ bug-gdb mailing list bug-gdb@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gdb
Re: GDB m68k debug multi-thread application fails: capability not available [PATCH 1/2] gdb-6.6-m68k-pthread.patch
Add the ps_get_thread_area function to m68k to provide debugging of
programs linked to libpthread. The code was copied from the MIPS
implementations in gdb and gdbserver.
diff -ur gdb-6.6.orig/gdb/gdbserver/linux-m68k-low.c
gdb-6.6/gdb/gdbserver/linux-m68k-low.c
--- /home/davidw/tmp/gdb-6.6.orig/gdb/gdbserver/linux-m68k-low.c
2011-06-23 09:09:53.977584261 -0500
+++ gdb-6.6/gdb/gdbserver/linux-m68k-low.c 2011-06-23 09:44:41.434490495
-0500
@@ -153,6 +153,26 @@
return 0;
}
+#include
+#include "gdb_proc_service.h"
+
+/* Fetch the thread-local storage pointer for libthread_db. */
+
+ps_err_e
+ps_get_thread_area (const struct ps_prochandle *ph,
+lwpid_t lwpid, int idx, void **base)
+{
+ if (ptrace (PTRACE_GET_THREAD_AREA, lwpid, NULL, base) != 0)
+return PS_ERR;
+
+ /* IDX is the bias from the thread pointer to the beginning of the
+ thread descriptor. It has to be subtracted due to implementation
+ quirks in libthread_db. */
+ *base = (void *) ((char *)*base - idx);
+
+ return PS_OK;
+}
+
struct linux_target_ops the_low_target = {
m68k_num_regs,
m68k_regmap,
diff -ur gdb-6.6.orig/gdb/m68klinux-nat.c gdb-6.6/gdb/m68klinux-nat.c
--- /home/davidw/tmp/gdb-6.6.orig/gdb/m68klinux-nat.c 2011-06-23
09:09:54.167562142 -0500
+++ gdb-6.6/gdb/m68klinux-nat.c 2011-06-23 09:41:10.319081266 -0500
@@ -67,6 +67,26 @@
45, 46, 47
};
+#include
+#include "gdb_proc_service.h"
+
+/* Fetch the thread-local storage pointer for libthread_db. */
+
+ps_err_e
+ps_get_thread_area (const struct ps_prochandle *ph,
+lwpid_t lwpid, int idx, void **base)
+{
+ if (ptrace (PTRACE_GET_THREAD_AREA, lwpid, NULL, base) != 0)
+return PS_ERR;
+
+ /* IDX is the bias from the thread pointer to the beginning of the
+ thread descriptor. It has to be subtracted due to implementation
+ quirks in libthread_db. */
+ *base = (void *) ((char *)*base - idx);
+
+ return PS_OK;
+}
+
/* Which ptrace request retrieves which registers?
These apply to the corresponding SET requests as well. */
#define NUM_GREGS (18)
___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb
