This is the mail archive of the
mailing list for the GDB project.
Re: Thread names in gdb7.7(using info threads command)
- From: Pedro Alves <palves at redhat dot com>
- To: Sreejith M M <sreejith dot mm at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 20 Aug 2014 10:06:12 +0100
- Subject: Re: Thread names in gdb7.7(using info threads command)
- Authentication-results: sourceware.org; auth=none
- References: <CAEDT3uRs2+mwV3_+2FNLchgNqQiLoip4x7_U4u6sRzSc=Seb0Q at mail dot gmail dot com> <CAEDT3uTC30arGwOJhqw-kL1T1sK=A5mzf-3hjnc6r6o6QfUuNg at mail dot gmail dot com> <53F37099 dot 9070307 at redhat dot com> <53F37252 dot 7070304 at redhat dot com> <CAEDT3uQXpyWpbGqh4Pde+ES9=O=rNNQbnmK5+PTGaMNJJPFkjg at mail dot gmail dot com>
On 08/20/2014 07:08 AM, Sreejith M M wrote:
> Thanks Pedro for the reply.
> To make things clearer, I get the thread names when I do live
> debugging( Run the image from gdb and crash)
> I am not getting the information only when I independently run the
> image and take the core dump to be analyzed in gdb.
> What my question is , whether coredump will have the required
> information or not.
Unfortunately, the Linux core dump format is underdocumented. You'll
have to web search and read sources to get more familiar with it, sorry.
Start by looking at /usr/include/linux/elfcore.h, and looking at bfd's and
gdb's sources for the structures defined there. Look around for info on
core notes (NT_PRPSINFO, etc.). The elfutils sources would also be another
As to whether the info is there or not, I'm not sure; you'll have to
experiment. Try using "eu-readelf -n" on the core, and see if the
thread name is there somewhere. I think it might end up in PRPSINFO/fname,
but I'm not 100% sure, and my time budget doesn't allow for
investigating further at this point, sorry.
> Why I am asking this again is because I did not
> understand how a gdb patch (as you have mentioned) can read the right
> data from core dump. Could you please explain a bit more?
> PS: I am newbie to gdb and dont understand the code quite well. If you
> can give some pointers, I will try to implement the patch if it is
See the target_thread_name calls in gdb/thread.c. When debugging
against a live target, that ends up calling into
linux-nat.c:linux_nat_thread_name, which extracts the thread name
out of /proc/PID/task/TID/comm. When debugging a core dump, that
target_thread_name call ends up in the corelow.c target_ops
implementation instead. You'll need to add a to_thread_name hook to
core_ops, that then calls info bfd to get the thread name somehow,
assuming the info is indeed there.
>> Or maybe it is, in NT_PRPSINFO / prpsinfo->pr_fname ? In that case,
>> all we'd need is a gdb patch to make use of it. See the
>> target_thread_name target method. We'd need an implementation in